T77> 3. Domains *used throughout entire system* would
T77> be great.

LS>> This has been discussed and there are a number of
LS>> semantic issues related to using Domains.
LS>>
LS>> Domains support a larger definition than 'simple'
LS>> data type, such as default and check/constraints.
LS>> Are these 'extended properties' to be applied each
LS>> time a SP is called?
LS>>
LS>> Additionally, Domains can be ALTERed. What is the
LS>> impact of ALTERing a Domain on the related SPs?

T77> I wouldn't have thought so. It's desirable for
T77> system-wide centralised consistency for sp/trigger
T77> parameter and variable datatypes and data-dictionaries.

MT>> Domains aren't just other names for datatypes.
MT>> It's a "domain", hence, the ability to add a check
MT>> constraint.

As a Firebird user, I don't actually _need_ other
new features in DDL or DML. But..

I think that "domain" seems in certain way "incomplete",
since it would be very useful to state at the beginning
of the db project each "type and _intrinsic_ constraint"
for each "type item" and then refer to that in the same
way in SP and triggers.

If this is not too complex to do, the use of one or two
"modifier" could solve the ambiguity in declaration.

Here two proposal:

TYPE_AS(<dom>): sounds like "<dom> without
constraint, only datatype"
DOMAIN_AS(<dom>): sounds like "Use type _and_
constraint as specified by <dom>"

Example:

..
CREATE DOMAIN D_PERCENT AS
DOUBLE PRECISION
DEFAULT 0
CHECK (VALUE BETWEEN 0 AND 100);
..
CREATE DOMAIN D_NAME AS
VARCHAR(32)
DEFAULT '<AVALUE>';
..
CREATE PROCEDURE P_DEMO(
P_NAME TYPE_AS(D_DNAME),
P_PERCENT DOMAIN_AS(D_PERCENT)
)RETURNS(
/* Here we don't need constraints, only
a "TYPE ALIAS" */
R_NAME TYPE_AS(D_DNAME),
P_PERCENT TYPE_AS(D_PERCENT) )
AS
..


Of course, one of the two "modifier" could be implicit.
A) "natural choice": "DOMAIN_AS" is implicit.
B) "practical choice": "TYPE_AS(..)" could be omitted
to mean "use the tipe as stated in domain", when
the parser recognise a domain in declaration.

Thank you for giving us firebird (in all its flavours)!