Re: index problem - Mailing list pgsql-general

From Tom Lane
Subject Re: index problem
Date
Msg-id 2625.960361213@sss.pgh.pa.us
Whole thread Raw
In response to Re: index problem  (Lincoln Yeoh <lylyeoh@mecomb.com>)
Responses Re: index problem  (Lincoln Yeoh <lylyeoh@mecomb.com>)
List pgsql-general
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.

Marcin's original create index command evidently managed to create
a pg_class entry with 32 non-null characters in the name field,
where it should have been only 31 and a null.  He couldn't delete
that entry with a drop index command using an unquoted name, because
the lexer would (correctly) truncate such a name to 31 chars.  But
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
just that the lexer created an invalid internal name string to
begin with.  Internally, no name should ever exceed NAMEDATALEN-1.

            regards, tom lane

pgsql-general by date:

Previous
From: Eugene Karpachov
Date:
Subject: Re: Releases: 7.0.1, 7.0.2
Next
From: Lincoln Yeoh
Date:
Subject: Re: index problem