Re: Missing ColLabel tokens
От | Peter Eisentraut |
---|---|
Тема | Re: Missing ColLabel tokens |
Дата | |
Msg-id | Pine.LNX.4.30.0101042312470.1245-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Missing ColLabel tokens (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Missing ColLabel tokens
|
Список | pgsql-hackers |
Tom Lane writes: > > (For the interested, the only other completely reserved tokens are TYPE > > and AS.) > > I suspect we're stuck on that for AS. However, TYPE is actually allowed > as a ColId, via the 'generic' production, so in reality it's not > reserved. I think this generic production might be a mistake. The productions go like this: generic ::= <ident> | TYPE ColId ::= <generic> | ... Generic ::= <generic> ConstTypename ::= <Generic> | (SQL type names) AexprConst ::= <ConstTypename> <Sconst> | ... SimpleTypename ::= <ConstTypename> | ... and then SimpleTypename is sort of a Typename. This allows TYPE to be used as a type name! All three of the statements select cast(42 as type); select type 'xxx'; create table foo (a type); fail with "ERROR: Unable to locate type name 'type' in catalog". Besides this there are no other productions making use of <generic>. I see this was introduced in gram.y 2.180, 2000-07-28, with a message of Fix acceptance of PATH as a type and column name.Note that this has changed some of the edge cases for what is acceptedasa type name and/or column id. Regression test passes, but moretweaks may be coming... which makes this look unintentional. TYPE could simply be under ColId and <generic> would simply be IDENT. Where's the harm? you might ask. I'm going to have to insert a special case into my extract-keyword-categories-from-gram.y (and make a DocBook table from it) tool. ;-) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: