Subject Re: [ib-support] [] or ""
Author Claudio Valderrama C.
""Ann W. Harrison"" <aharrison@...> wrote in message
> At 09:49 AM 10/26/2001 -0500, Woody wrote:
> Throughout the engine there are routines that compare names. If I had
> added quoted identifiers, I hope I would have had the sense to centralize
> those operations - something we may yet do to allow native language and
> long names. As it is, there is code everywhere that had to be taught to
> deal with spaces, for example. Claudio can expand on that, having found
> at least 4 different places that hadn't been fixed.

Hi, these are SOME (and I'm not kidding) of the bugs that were fixed in
Firebird, caused by the nefarious quoted identifiers:

[ #450405 ] Tricky role defeats basic SQL security

[ #460621 ] Blob API v/s embedded blanks in names

[ #229231 ] Revoke is case sensitive

[ #227760 ] Zero-length db object names shouldn't be allowed

[ #227758 ] Field names with spaces cannot be used in VIEWS

[ #226456 ] SELECT/PLAN does not understand delimited SQL index names

In addition, Ann did once things like
insert into tbl("field ") values(something);
select "field " from "tbl " where condition;
while discussing indentifiers in IB-Architect but the statements failed. I
had to fix them because trailing blanks weren't trimmed in all cases.

Even the humble gstat and the services API call that it implements had the
same problem until a few weeks ago when I fixed a function, but I didn't put
the failure in our tracker.

And there's another: the DFW (Deferred Work Handler) suffered from the same
hiccup in some place. I don't want to be tragical because I didn't try a
real example, but failure to compare two names with embedded blanks that are
the same (but were seen as different) could potentially lead to incorrect
metadata storage.

The code was prepared to stop at the first blank seen and to uppercase
everything or assume anything comes already uppercased. Only 3/4 of the code
was updated when IB6 was open sourced. This is why I continue using

For example, there's still the same old logic at PAR_symbol_to_gdscode() but
I think it's harmless, because the names used (from codetext.h) are always
in lowercase and with underscore in the middle.

Claudio Valderrama C. - -
Independent developer
Owner of the InterbaseĀ® WebRing