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?
Ann W. Harrison answers:
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.