RDB$UPDATE_FLAG description is wrong for RDB$RELATION_FIELDS

[the-Arioch]

Current English description (from 2.5 to 4.0) claims the field is telling computed columns from non-computed ones.

But that is hardly so. On my legacy table in Firebird 2.1 i can see only TIMESTAMP columns having RDB$UPDATE_FLAG=1

Other users get confused too - example https://stackoverflow.com/questions/68451712

P.S. Though it is still interesting which legacy unmantained checks are actually written into that column.

[the-Arioch]

https://sourceforge.net/p/firebird/mailman/message/37323005/ - the column is de facto unused and mostly unmantained.

My two cents that the very column better be just removed. For example my first thought was about updatable/read-only views rather than computed columns (then i recalled that at least in SQL a view can not be updateable on one columns and non-updateable on others).

If that column is so rusty and dusty that even gbak does not fix it - better just drop it altogether using FB4 milestone as an excuse (a bit late, but still). Since the column is so unreliable - no one could use it anyway, and did not.

Unless someone wants to take a burden of formulating semantics (the exact set of criteria when column is [not] updateable) and then mantaining it through docs and FB sources (all of the programs including GBAK and GFIX) and test suites, today and ever.

Also, try to think up a GOOD documentation that would describe this column as it factually is now, with all those "newer versions bla-bla, older versions - rah-rah, GBAK foo-foo) and yet still being concise.

So, just good riddance, with next FB4 milestone.

[mrotteveel]

I'm going to leave the documentation as-is. As to your suggestion to remove the column, this repository is not the right place for such suggestions, please discuss on firebird-devel, or create an issue on https://github.com/FirebirdSQL/firebird.

[the-Arioch]

That means this situation would just repeat itself.

The documentation clearly is not correct as it does not describe the reality.

What to do about it and which FB subprojects to be changed is complex question. But the fact that the documentatio nas it is now can not be trusted and leads users to dead end is a fact.

[mrotteveel]

The documentation is correct, Firebird 2.5 and higher(*) populate RDB$UPDATE_FLAG with 1 for normal columns and 0 for computed columns when creating new columns. That this wasn't retroactively fixed for columns created in older (or buggy) versions is unfortunate, but if you want to do something about that, file a ticket in https://github.com/FirebirdSQL/firebird/issues to have gbak correct wrong RDB$UPDATE_FLAG values when restoring a database. Addressing this in the documentation is the wrong type of fix.

*: I didn't check older versions.

[the-Arioch]

"when creating new columns" does documentatio say so? That only databases created from script in 2.5+ are having correct values?