""Woody"" <woody.tmw@...> wrote in message
news:00ea01c1db35$ea7d14a0$786222d1@popstoy...

> From: "Thomas Steinmaurer" <ts@...>
> >
> > select extract(month from current_date) from rdb$database
>
> A side question, please, somewhat related, I say sheepishly. <g>
>
> On several Borland newsgroups, it is being touted more and more that it is
> not a good idea to continue using syntax using the RDB$DATABASE table. The
> reason is that at some point in the future, the rights to that table might
> be changed, breaking all kinds of code.

Are you sure you didn't pick an April fool's Day post?
Restricting R/W permissions on system tables is right, but why would Borland
want to break apps that have worked since IB4? Is it necessary to block R/O
access to rdb$database? Is their IQ so limited? Which is the confidential
information that rdb$database holds? I assume they are going to put the
db-wide charset in another table if it can't be queried anymore in
rdb$database by non-privileged clients.

> Is there any talk about this on the
> Firebird side?

No, but here's one proposition:
- We'll forbid any access to rdb$relations. You won't be able to list your
tables anymore.
- We will create a Services API call to get the list of tables. We will
modify isql accordingly.
- We will return the information in the traditional UUENCODE format through
the Services API.
- We'll forbid access to rdb$triggers. You won't be able to read neither the
source code nor the generated BLR. But since this is the only way to get the
source of a check constraint, we will take advantage of our special system
flag values for check constraints and will provide that information through
the Services API. Since we don't want to bore you with the same format
again, we'll return the sources in hex format.
- To discourage casual snoopers, we will return only the first three letters
of each procedure's name as stored in rdb$procedures. You will be able to
get more letters by way of a new grant option we will implement:
grant <n> characters on rdb$procedures to <user|role>
If you choose the special value -1 for <n>, we will return pseudo-random
names.

Also, we are bored with the current C/C++ scheme. Our new public API will be
using Eiffel and Oberon.

> The newly recommended style is to create a one row table to
> use for this purpose only and substitute it for RDB$DATABASE.

The new style will be: you either write down your relations' names in a
sheet of paper, keep them in your brain or learn uuencode. We can always
make worse decisions than the other side if we keep trying hard.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing