At 10:41 AM 4/19/2001 -0400, Leyne, Sean wrote:

>I think the scope of this discussion about user connection information,
>needs to be expanded and perhaps framed in a context which includes the
>replacement of most UDF with internal server functions.

I would like to move the discussion to IB-Architect to get the
opinions of several people who don't follow this list - Ms. Brown
& my friend across the desk for starters. There may be people on
this list who don't follow the Architecture list. You should.

There seems to be wide agreement that there are a number of bits of
user information that could be useful. How many and which ones are
not yet determined. We have proposed a number of means of acquiring
the information, including info calls, system function calls, pseudo
tables, blr value expressions.

First question: Where are these values needed?

Ann's answers: Applications, including applications using higher
level tools. Stored procedures and triggers. Firebird today.
Not Netfrastructure. Not the totally re-imagined Firebird of the
future with all Java embedded programming and robotic ears.

Second question: Should we follow existing architectural patterns
or invent something {better | different | incomprehensible by mortals}?

Jim Starkey suggests:

>.. a) Info calls (request, transaction, database),

Not accessible to procedures/triggers.

> b) blr value expressions and the ilk,
>Blr value expressions eat into blr space, require non-standard
>SQL syntax to support them (oh, look, Jim is arguing against
>non-standard!). They also don't lead to returning complex
>data (multiple role, each with active indicator).

The mechanism I suggested uses one value from the blr space
for as many items as we can imagine. The "non-standard"
syntax would follow the "standard" mechanism that now returns
a user name, making it transparent to application layers.
(i.e. FB_CONNECTION, FB_TRANSACTION, FB_ROLE ...). I
don't know how to represent multiple roles, but at the moment
Firebird doesn't allow changing roles, let alone holding
multiple simultaneous roles.

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

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


Sean Leyne suggests:

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

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

>The issue of the actual BLR, pales in comparison with the effort
>currently required to add new system functions to the engine, which
>based on the current implementation, would require changes to some 20
>different code files.

Actually, not true. The actual BLR determines compatibility and
must be worked by two groups who aren't getting on well together.
The rest is SMOP.


Regards,

Ann
who is sick, tired, and cranky (as if you didn't know)