At 03:00 AM 07-06-2000 -0400, Tom Lane wrote:
>Lincoln Yeoh <lylyeoh@mecomb.com> writes:
>> At 10:53 AM 05-06-2000 +0200, Marcin Inkielman wrote:
>>> drop index oceny_stud_numer_albumu_protokoloceny_stud;
>>> failed....
>>> so I used:
>>> drop index "oceny_stud_numer_albumu_protokoloceny_stud";
>>> and it worked for me 8-)))
>
>> I wonder why it worked tho. How does Postgresql treat stuff between double
>> quotes, especially regard to string length limits?
>
>Stuff between double quotes *should* be subject to the same
>NAMEDATALEN-1 restriction as unquoted names. Embarrassingly, 7.0's
>lexer didn't enforce such a limit (it's fixed in 7.0.1 and later)
>which meant that you could overrun the space allocated for names
>in pg_class and other system tables, if you quoted the name.
>
>evidently it worked to match against a quoted-and-not-truncated
>name. I'm pretty surprised that he didn't see coredumps instead.
>
>If you want to trace through the code to discover exactly how it
>managed to avoid crashing, go for it --- but it doesn't seem like
>an especially pressing question from here. To my mind the bug is
Well for some reason things like these tend to set alarm bells off in my
head with a blinking "security" sign :). But of course in most
environments, untrusted users don't get to define their own names (I recall
someone talking about a million table thing, hopefully those tables are
given internally defined names).
Cheerio,
Link.
