Adam wrote:

>
> Is there any plans to allow you to define the input, returning
> parameters and variables within stored procedures (and variables
> within triggers) by using domains?
>

It's been discussed at some length on the development lists.

The easier change would be domain support for procedure parameters.
They're already represented in RDB$FIELDS, the system table for domains,
but only as system created entries specific to the particular parameter.
Generalizing that would not be difficult, but does involve making some
decisions. Domains currently include constraints. How should
constraints be handled for procedure parameters? And what happens to a
procedure when the constraint on the domain of one of its parameters
changes. Some people argue that you shouldn't be allowed to change even
the data type information on a domain used by a procedure parameter,
which makes the use of domains pretty lame (personal opinion, not
universally shared).

The harder problem is procedure variables. When a procedure is defined
it is compiled into BLR and the variables become BLR structures. Tying
them back to domains would be a mess, particularly when propagating
changes to the domain.

Both changes should (personal opinion warning) be left until after the
Vulcan merge and probably the issue of variables based on domains should
follow the elimination of the BLR intermediate representation.

Regards,


Ann