>>> ...if this was provided, we would get
>>> inundated with complaints that the constraints and defaults
>>> were not applied

>>> As long as it is well documented, we can always tell them
>>> to RTFM.

>> Maybe it's just that this is a Monday, a local holiday,

> It's a local holiday here too.

Well its not a holiday here but...

>> and a beautiful day

it is a beautiful day, however...

> Lucky you. Here it's rain and supposed to be a downpour of
> almost 2 inches of rain later today.

We certainly would not complain if we got some rain.

[ Thats got the formalities out of the way :-) ]

>> and I'm stuck in the office, but as a general rule, features
>> should be designed so they work as expected.

> No arguments from me. But, the "work as expected" can defer
> from person to person. In this case, with the domains, I
> would be happy with just using the datatype of the domain.
> And, I'm sure others would want the constraints as well,
> which could be beneficial in most cases. As well as supporting
> the default values, but that can cause problems if passing a
> parameter a NULL value which might be expected to pass would
> be changed to the default value of the corresponding domain,
> which is used for the datatype of that parameter. But, then
> again, that would be the user's problem.

To be honest I could live with either implementation (with or
without constraints etc).

SP input variables would be validated when the SP starts, next
internal and return variables would be initialised with domain
defaults. And then user code can start, with all variable
assignments validated through domain constraints.

Great, I could live with this. Certainly I would probably
need to create some extra domains to support the various times
when an SP or trigger needs a slightly more flexible domain,
but better this than the current situation of no domains.

Keep in mind that, if you support the full default/constraint
definition of a domain, then people are also likely to want
the same syntax as fields - letting variables be declared with
their own defaults and constraints directly (instead of just
through a domain). Not what I want, but it would be consistent
with supporting full domain definitions.

Equally well I could live with domains in SPs and triggers
using domains only as data types. In most cases the code is
there to support manipulation of values into or out of a table,
in which case much of the data has already been validated. In
other cases, well type-safety has never been a big thing with
SQL, so code needs to take special care anyway.


I have no idea how hard either implementation would be, I am
guessing that neither would be easy. But it really would be
a boon to database maintenance.

--
Geoff Worboys
Telesis Computing