Re: Missing ColLabel tokens - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Missing ColLabel tokens
Date
Msg-id Pine.LNX.4.30.0101042312470.1245-100000@peter.localdomain
Whole thread Raw
In response to Re: Missing ColLabel tokens  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Missing ColLabel tokens
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Missing ColLabel tokens
Next
From: Tom Lane
Date:
Subject: Re: Missing ColLabel tokens