Hello Dmitry,

> > >Would you be happy with BASED ON functionality? This way, it would take
> only
> > >the data type and everybody's clear it's not the whole domain.
> >
> > I like that idea - and tracking datatype changes is MUCH easier than
> > deciding how (and when) to apply constraints, etc.
>
> Generally, I agree with the idea too. Although when I was discussing this
> feature in another forum, I suggested something like typeof(<domain>) to

be

> even more clear. But this is just a syntactic sugar.
>
> We have two issues to take into account:
>
> 1) FB 2.0 introduces default values for procedure parameters, and they're
> obviously stored in system-generated domains. In this case my typeof()
> suggestion doesn't match the semantics, while BASED ON still may be used.
> But, to provide the same level of functionality, BASED ON should use

domain

> defaults. We cannot use BASED ON <MY_DOMAIN> DEFAULT 'QWERTY', because
> there's no place to store 'QWERTY' except domain MY_DOMAIN which may

already

> contain another default value.

Do as RDB$RELATION_FIELDS does -> add a column to
RDB$PROCEDURE_PARAMETERS to override the domain
default. If it's FB2, the ODS is allowed to change, right?

> 2) When we later will be ready to reliably support e.g. check constraints

in

> procedure parameters, the syntax should be ready for that. Again, BASED ON
> looks more appropriate in this case. But any such extention may break
> existing databases, as they may rely on a fact that BASED ON feature

ignores

> check contraints.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com