Re: index problem
| От | Lincoln Yeoh |
|---|---|
| Тема | Re: index problem |
| Дата | |
| Msg-id | 3.0.5.32.20000607152405.008b8e20@pop.mecomb.po.my обсуждение исходный текст |
| Ответ на | Re: index problem (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: index problem
|
| Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: