Hi Dmitry,

> > > 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?
>
> Doable. Should the engine store the default value for "A INT = 1" in
> RDB$FIELDS or in RDB$PROCEDURE_PARAMETERS then? You may say that only
> overrides of the existing domains should go to RDB$PROCEDURE_PARAMETERS,

but

> I may object that system-generates domains are the existing ones with the
> not-specified default value being overridden ;-)

Do it the same as it's done now.

As far as I know (without checking), if there's a default, it's in
RDB$FIELDS
and overridden defaults (for non-system domains) go in
RDB$RELATION_FIELDS. So this should be the same for parameters.

A parameter that's based on a normal datatype should have its default in
RDB$FIELDS. A parameter based on an existing domain should have its
default in RDB$PROCEDURE_PARAMETERS.

I believe it is done as such.

With regards,

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