Hi!

We now have the ability to use domains in PSQL, but use custom domains
for all table columns is not good.
Generally, domains is good for key columns, so you use it in the primary
key and use the same domain in the foreign keys.

But procedures and triggers many times should handle this non-key
columns, so you currently have two alternatives:
1) Use domains for all columns and use the same ones in PSQL
2) Don't use domains and use the same type in PSQL

It's very great to be able to declare parameters or variables using the
same type of a table column.

Oracle has it with the syntax "table.column%type", example:
declare name employee.name%type.

This syntax sound not good for FB, and we need to support it both with
and without "TYPE OF" prefix.

But using only table.column syntax is likely to be ambiguous when we
have schemas, as it may represent schema.domain.

I suggest we use syntax "column table.column", that is also consistent
with syntax for COMMENT ON COLUMN, example:
declare name1 type of column employee.name
declare name2 column employee.name
cast(name as type of column employee.name)
cast(name as column employee.name)


Implementation:

Add columns RDB$RELATION_NAME and RDB$FIELD_NAME to
RDB$PROCEDURE_PARAMETERS.

When type of a column (RDB$RELATION_FIELDS.RDB$FIELD_SOURCE) is changed,
the change is propagated to RDB$PROCEDURE_PARAMETERS.RDB$FIELD_SOURCE
using this information.

Create a new verb blr_column_name (constrained/type of, table name,
column name), with same semantics of blr_domain_name.

All logic of domain type change is extended to column type change, i.e.,
to invalidate/recompile procedures and triggers.

Comments?


Adriano