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
I think this generic production might be a mistake. The productions go
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 accepted
as a type name and/or column id. Regression test passes, but more
tweaks 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(at)gmx(dot)net http://yi.org/peter-e/
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-01-04 23:25:01|
|Subject: Re: Missing ColLabel tokens |
|Previous:||From: Dave VanAuken||Date: 2001-01-04 22:04:50|
|Subject: running pgsql 7 under Jail'ed virtual machine on FreeBSD 4.2|