Adriano,

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

First, why some constraints (NOT NULL) are applied whilest others (check
ones) are not? This doesn't look consistent to me.

Then, it we inherit *all* constraints, I think we should use a plain domain
name without the BASED ON clause, so the usage syntax and semantics would be
the same as for tables. If we apply *no* constraints, then BASED ON sounds
fine to me. Although if we talk about datatypes only, I'd prefer something
like TYPE OF <name> instead. Moreover, both alternatives could co-exist:

CREATE DOMAIN BOOLEAN AS SMALLINT CHECK (VALUE IN (0, 1));
DECLARE MY_VAR BOOLEAN; -- constraints are applied
DECLARE MY_VAR TYPE OF BOOLEAN; -- constraints are ignored

> 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.

Per SQL-2003, CAST(<value> AS <domain name>) is perfectly legal, so I agree
here.

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

And 17.11.1858 for dates? :-)

> Variables are internally created with new "blr_based_on <name>",
> hence domain changes are automatically propagated.

Okay, but it can easily make the PSQL code broken if the type change is done
in a not compatible way (e.g. a CHAR->INT change). Do you want to prohibit
that based on dependencies? Or do you plan to control BLR invalidation and
throw an appropriate error?

> 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, ...

And I foresee INTEGER CHECK(...) in the future :-)

Also, what's about non-SQL procedures? Will the constraints work for them
too?

Thinking about that, I'm already not that sure that constraint definitions
should be allowed for parameters and variables. For a table, it's just an
alternative to an user trigger, so it saves you one object definition. In
PSQL, however, you need to write a PSQL body anyway, so IMO it's not a big
deal to add an IF statement in the beginning.

> 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.

And then also RDB$VALIDATION_SOURCE / RDB$VALIDATION_BLR? Is such a
complexity really worth the value?

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

Agreed. But I'm mostly worried about validation of the BLR (see above).


Dmitry