> The question is whether it makes more sense to build (or plug) the
> semantics into the data definition and engine where it can be
> intelligently used by various subsystem, or require every reference
> in every store procedure, trigger, and application code to make
> a hard reference to the type.

The other question is to either allow a developer to have full control over thier
data types (however primitive or complex) or wait till someone builds the
particular feature into the new version (whenever that occurs).

Alot of the current UDF's would be unnessary with this ability.

It does not eliminate the developers ability to use udf's, but it does extend the
flexibility of the database without undue complexity.

> If you back and take a look at embedded GDML, designed to avoid
> the problems of hard coding types and lengths into host programs,
> and contracting that with the pain and suffering induced by
> either embedded SQL or dynamic SQL, I think you will see the
> benefits.

I have found that thier has been no pain with server side embedded SQL. This is
where the features would be preferred, as an extension to the SP language. Most
of my apps call stored procedures and do little to no processing on the client.
This makes upgrading and supporting different platforms very simple. It would be
nice to be able to do alot more system processing on the server without client
interaction (other than to start the process and commit when finished).

Dalton