Hi!

Based on past discussions I've done a prototype implementation allowing
domains and NOT NULL to be used in PSQL.
See that as another call for discussion on the topic.

It was implemented using the "BASED ON <name>" approach, so check
constraints are not applied.
NOT NULL from domain is used.

Could be used in SP/trigger/block parameters (input and output) and
variables.

It should be usable in CAST too. But BASED ON syntax is not good for CAST.
Currently it works in CAST without BASED ON prefix.

NOT NULL parameters/variables are initialized to data type default
value, i.e., 0 for INTEGER, etc.

Variables are internally created with new "blr_based_on <name>", hence
domain changes are automatically propagated. NOT NULL from domains is
get inside the engine only with the domain name.

Explicit NOT NULL data types are prefixed with new blr_not_nullable.
Examples:
INTEGER NOT NULL -> blr_not_nullable, blr_long, ...
BASED ON CUSTOM_TYPE NOT NULL -> blr_not_nullable, blr_based_on, ...

NOT NULL (from the domain or explicit) are flagged in the descriptor and
assignment of NULL to it are prevented at EXE_assignment.

Things not implemented yet:

Explicit NOT NULL of parameters should be stored at some other place.
Logical candidate is RDB$PROCEDURE_PARAMETERS.

Default parameters of SPs in V2 are stored at the implicit created
domain, so it's the same situation as above.

Variables aren't initialized with the DEFAULT value of domain.
Seems strange, parameters are and variables no.
And output parameters?
Opinions?

When a domain change, should be necessary to invalidate the procedure cache.
Could be done using the stored dependencies.

Comments?


Adriano