Re: [Firebird-devel] The invisible generator and the rdb$ prefix

[Jim S. <ji...@ji...>]

The wolf in Manchester pleads not guilty.  A cursory examination of the 
Vulcan code exposed the following code snippet in MET_lookup_index_name:

         if (!gen_id) {
             strcpy (name, "RDB$GENERATORS");
             return;
         }

Any student of wolf-code will understand that the wolf never, ever coded 
in that style.  The wolf would have matched the braces and put a blank 
line before the return.


On 3/30/2014 3:04 AM, Claudio Valderrama C. wrote:
> Oedipus found the sphinx near Thebes and the monster asked:
> "what is the thing that cannot be seen but can be called by name to change
> it?"
> Oedipus replied "it's RDB$GENERATORS" and the sphinx committed suicide.
>
> Now if we replace the sphinx by a wolf, the wolf at Massachusetts asks:
> "in the release build I do CREATE GENERATOR RDB$GENERATORS; then how do I
> use it?"
> Nobody can answer. We are doomed. The system ties this name to the zeroth,
> invisible generator. It's hardcoded and the new generator that unwittingly
> stole the name is ignored. Using gen_id on that name will alter silently the
> sys gen, not the user gen. Only the debug build stops this creation with an
> assertion.
>
> To the dismay of Sean, I continue saying that while we don't declare "name
> independence" and continue relying on RDB$ for some decisions, it's better
> to forbit the RDB$ prefix for user objects. See, for example:
>
> SQL> create domain rdb$cats int;
> SQL> create table rdb$cats(rdb$cats rdb$cats);
> SQL> drop table rdb$cats;
> SQL> commit;   <--- just to be sure
> SQL> show domains;
> There are no domains in this database
> (Now it's clear the explicit domain was wiped out just for using the wrong
> prefix.)
>
> I've seen other cases, it seems that they're stored in the tracker. Implicit
> objects could have a special sysflag value, but this is not a change that
> takes three minutes and can upset third party tools.
>
> Other things we should protect... by name for now, until we have more
> sysflags:
>
> SQL> show domain rdb$linger;
> RDB$LINGER                      INTEGER Nullable
> SQL> alter domain rdb$linger type bigint;
> SQL> show domain rdb$linger;
> RDB$LINGER                      BIGINT Nullable
>
> I should not be able to spoil a sys domain. I can't go back because the
> system protects the data integrity:
> SQL> alter domain rdb$linger type int;
> Statement failed, SQLSTATE = 42000
> unsuccessful metadata update
> -ALTER DOMAIN RDB$LINGER failed
> -Cannot change datatype for RDB$LINGER.  Conversion from base type BIGINT to
> INTEGER is not supported.
>
> C.
> ---
> Claudio Valderrama C.
> Consultant, SW developer.
>
>
> ------------------------------------------------------------------------------
> Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel