At 12:12 PM 4/19/2001 -0400, Leyne, Sean wrote:

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

Oh, sigh. Two mechanisms - one result. Or more likely, two
mechanisms, two vaguely related results.

>...list all the users ... connect time?... or a long
>running transaction ...

Too true.

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

Right.

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

Somehow I suspect we will run into other information that doesn't
resolve to a single value. Transactions, for example ... a cross-database
transaction has at least three transaction identities - one for each
database and one for the combination....

Sean had said:

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

I responded:

>That looks to me like a higher level access issue.

Sean replied:

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

Ah, but the underpinnings of those functions are blr_upper, blr_extract,
blr_min, & blr_max.

I said (cryptically)

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

Sean asked:

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

Firebird is a BLR engine - requests are sent to it in BLR, it
parses the BLR, generating intermediate action nodes. The action
nodes are compiled into data access strategies which are executed.

BLR is a byte code. At one time, 255 values seemed like enough to
express anything anyone could want from a database. No more.
So, we increase the effective space by using two values to indicate
that the subsequent values are functions - scalar functions if they
take a single set of arguments, aggregate functions if they take an
arbitrary number of input sets.

The syntax of blr_min, for example, is
blr_min, <value>, <value>

I'm suggesting that the syntax for tangent might be
blr_scalar_function, blr_tangent, <value>

That puts blr_tangent (and all its relatives) in a different
name space from the primary blr elements.

sorry if this is totally unclear - it's really quite simple and
minor and really only serves to address the issue of blr name space
restrictions.


Regards,

Ann
www.ibphoenix.com
We have answers.