Ann,

You wrote: (excuse the quoting style, my MS outlook does a poor job of
it, so I'm doing it manually)

>c) results sets from pseudo system tables

This is also the mechanism that Dave Schnepper suggests, and
frankly, arguing against Dave and Jim when they agree is never a
good sign. Transparent, yes. Extensible, yes. Totally new
mechanism yes. Do I want to go there? No.


I agree, pseudo table suggest a pseudo answer.

Actually, let me retract that. I think that pseudo tables could have
some good benefits but in *conjunction* with the 'functions' we have
been talking about - you should not have to perform a SELECT to get the
information about your connection from within a trigger or SP.

How many times have people asked to list all the users who are connected
to the database and their connect time? Or, which user has a long
running transaction which is not committed yet and is affecting the
sweep process?

Pseudo tables for this type of information would visualize all this
information, and allow developers/DBAs to do as they please.

You also wrote:

>d) system defined "udfs".
>
>System defined UDF, like the doomsday function but without
>the side effects, would be easy and embeddable in stored
>procedures.

Doesn't handle the multi-role problem any better than
the blr suggestion.


As Diane will probably point out, SQL does not allow for multiple user
roles.


You also wrote:

>I think of the accessing of user information like a system function

call

>- CONNECTION_ID(), CONNECTION_IP(), CONNECTION_DATETIME(). The
>functions would access and extract the information from new
>server/connection/transaction objects.

That looks to me like a higher level access issue. There are
currently no system function calls, nor any mechanism for describing
them. Sure, the lexical token FB_CONNECTION could be CONNCECTION_ID()
but it won't affect the underlying issues.


I guess we are using different semantics/vocabulary, I think that
UPPER() and EXTRACT() qualify as system functions. This definition
could also be extended to include MIN and MAX.

You also wrote:

>As we have discussed privately, since the number of available BLR codes
>is not large enough to include all the current UDF functions, the use

of

>multi-bytes codes will be required.

We started that discussion and never really got to my suggestion
which is similar to the one that started this. Use two of the
remaining 82 blr codes to define blr_scalar_function and
blr_agg_function.
That reopens the blr name space for functions.

Perhaps I (and others) need a tutorial on the meaning of
blr_scalar_function and bld_agg_function and their context in this
discussion.


Sean