All,

Some [short-sighted] person has decided to use datatypes directly instead of
system-generated domains for function arguments and return value. So when we
come to supporting the "domain as a type" feature, it won't work for SQL
functions. It's not a big problem to solve, but what should we do with the
current columns that would become deprecated? Another example: at some point
in the future we could want to normalize our system schema and introduce
RDB$OBJECTS that would encapsulate the common stuff like name, system flag,
owner, description, etc. Again, we have a scenario when some existing
columns become deprecated. As you know, we cannot drop them, because the
database downgrade requires old GBAK which expects to see those fields, and
we should also care about regular backward compatibility.

So, how should we handle this issue? Below are the options I can think of:

1) Database restore populates the deprecated columns, but the engine ignores
them. Backward compatibility is limited - new schema objects (created in new
ODS) cannot be downgraded succesfully.

2) Same as above, but the engine writes to both new and deprecated columns.
100% compatibility, but code duplication.

3) Deprecated columns are declared as computed ones. IMO, it should also
provide 100% compatibility at the SQL level, but I'm not that sure for
GDML/BLR. Also, having computed columns in system tables doesn't look as an
extremely good idea to me.

Opinions? Any other options?


Dmitry