At 02:09 PM 11/29/2004, Nando Dessena wrote:

>Ann,
>
>A> REL_permanent_GDML = 2
>A> REL_permanent_SQL = 3
>...
>A> REL_local_temporary_GDML_preserve_on_commit = 122
>A> REL_local_temporary_SQL_preserve_on_commit = 123
>
>I can't see the difference; it still needs ugly queries.

Ah, but I thought the problem was using bit values in a
system that doesn't have bit operators? And, of course,
the two proposals are identical. That was the point.
The rdb$types table could easily support translation
from the values in rdb$relations.rdb$flags to strings.

>I don't think it's of paramount importance, but it has to be decided
>if this information is intended for user consumption or just internal
>engine working. In the former case, providing something that can only
>be dealt with with bit algebra, and not providing the necessary
>operators in SQL is subtly cruel.

Subtle? Hardly. But not all that different from data types or
any of the other values that are stored in binary despite the
notorious inability of people to read bits. The original intention
of the system tables was two-fold. First, to provide the information
the system needed to run itself. Second, to provide information that
intelligent utilities could use to describe the database to users.

> Not to mention that stuffing all
>that info in a single column violates the most basic normalization
>rules, which is ironic for a field whose name starts with RDB. ;-)

Would you prefer to see a series of fields like these?

RDB$PERMANENT_RELATION char(1)CHECK (VALUE IN ('Y', 'N');
RDB$ON_COMMIT_PRESERVE char(1)CHECK (VALUE IN ('Y', 'N');
RDB$GLOBAL char (1)CHECK (VALUE IN ('Y', 'N');




Cheers,


Ann