While I quite agree with the need, how about an alternate approach.

There is plenty of reason to expose more system information - and it
seems a more useful way to expose it is via system pseudo-tables.
Such a table would not be under transaction control, not exist
on disk, but could be queried through normal SQL methods. (if anything
is
normal in SQL).

Totally off the cuff,

create table rdb$sessions (
rdb$session_id integer not null primary key,
rdb$start_time timestamp,
rdb$user char(x),
rdb$role char(x),
rdb$character_set char(x),
rdb$client_name,
rdb$protocol,
rdb$address (etc)
whatever else seems useful...)

create table rdb$transactions (
rdb$transaction_id integer not null primary key,
rdb$session_id (references rdb$sessions.rdb$session_id)
rdb$statements_executed, rdb$rows_modified, etc.)

Heck, for that matter, perhaps these should be on-disk structures.
(Ouch, No, I didn't mean it!)

Dave

> -----Original Message-----
> From: Ann W. Harrison [mailto:aharrison@...]
> Sent: Wednesday, April 18, 2001 1:29 PM
> To: bpi_opensource@...; IB-Architect@yahoogroups.com;
> firebird-devel@...
> Subject: [IB-Architect] planning the use of blr codes
>
>
> A number of people have asked about adding some
> "built-in" values, including ROLE, TRANSACTION,
> and CONNECTION.
>
> My immediate reaction is "you don't need to know
> that," but the statement reminds me too much of
> some operating system developers I've dealt with
> who explained patiently that if I were doing anything
> that required knowing the operating system version,
> I was doing something wrong. So I feel guilty.
>
> And, of course, there are good reasons for knowing
> the role which have been explained widely. And
> there are legitimate reasons for knowing the transaction,
> having to do with replication. And, for those who
> insist that everyone sign on as SYSDBA, I guess knowing
> the connection is important too. Besides, having lost
> the previous two arguments, I'm already in full retreat.
>
> So, what would the world think of reserving 174 to
> be blr_user_id. That would take a single blr argument
> which would be one of the set
>
> blr_user_transaction
> blr_user_connection
> blr_user_role
> ...
>
> where ... would expand as necessary.
>
>
> Thoughts?
>
>
> Ann
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/