Hi Ann,

I probably should have stated that

a) For the interim I am happy to work around it the way I have for
the past 1.5 years

and

b) I am aware of how complex the changes will be (I thought about the
consequences of altering or dropping a domain causing problems etc)

> 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?

The same way you handle someone trying to put an integer into a
varchar field or a string into a timestamp. If I define

CREATE DOMAIN TBLID AS INTEGER check( value > 0 ) NOT NULL;

And someone tries to use a parameter of -1, then it is an invalid
typecast (or whatever the error is). It is as wrong (from a business
rules perspective) as trying to insert 'Adam' into such a field.
Obviously, just my personal opinion

And what happens to a

> procedure when the constraint on the domain of one of its

parameters

> changes.

I imagine it would have to recompile.

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).
>

I share your view.

> 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.
>

I agree, the source would have to be retained in some form and
dependancies on the domains would need to be stored. If a change is
made, the procedures would be recompiled to reflect the changes.

> 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.
>

Thats fine. The work around is pretty simple. I have no doubt that I
have oversimplified the problem, and stuff that no-one has yet
thought of will probably make it even harder, but I still think that
in the long run this will be a very powerful feature.

Adam