Thread

1. RE: create table bug with reserved words?

   Chris Storah <cstorah@emis-support.demon.co.uk> — 2001-02-16T09:27:43Z

   According to the documentation, CALL is in as a reserved word (7.1beta4 docs
   I think).
   
   The problem I have (and others may get) is porting apps from other databases
   that support reserved words as identifiers (SQL server being the main one).
   
   I assume the parser should know where it is (first and follow sets would
   define whether a reserved word is allowed or not?), so is there any reason
   why an identifier cannot cope with reserved words?.
   
   If not, can anyone point me in the direction of the code that does the
   parsing so I can take a look - if this would be helpful!
   
   Thanks,
   Chris
   
   -----Original Message-----
   From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
   Sent: 15 February 2001 15:23
   To: Chris Storah
   Cc: pgsql-bugs@postgresql.org
   Subject: Re: [BUGS] create table bug with reserved words? 
   
   
   Chris Storah <cstorah@emis-support.demon.co.uk> writes:
   > Is this a bug - should the parser cope with any reserved words as
   > identifiers?
   
   No, and no.  If you could use them as identifiers then they wouldn't
   be reserved words, would they?
   
   Some keywords are "more reserved" than others in the Postgres parser;
   see the distinction between ColId and ColLabel in gram.y if you want
   the details.  AFAICT, "CALL" is not a keyword at all in Postgres.
   
   			regards, tom lane
   
   

2. Re: create table bug with reserved words?

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-16T16:19:56Z

   Chris Storah <cstorah@emis-support.demon.co.uk> writes:
   > If not, can anyone point me in the direction of the code that does the
   > parsing so I can take a look - if this would be helpful!
   
   src/backend/parser/gram.y.  If you find that anything more can be moved
   out of the truly-reserved or ColLabel categories and added to the ColId
   category, let us know!  But I think everything that's in ColLabel is
   there because you get parsing conflicts otherwise ...
   
   			regards, tom lane
   
   

3. RE: create table bug with reserved words?

   Peter Eisentraut <peter_e@gmx.net> — 2001-02-16T16:33:31Z

   Chris Storah writes:
   
   > According to the documentation, CALL is in as a reserved word (7.1beta4 docs
   > I think).
   
   According to the documentation at
   http://www.postgresql.org/devel-corner/docs/postgres/sql-keywords-appendix.htm,
   CALL is not a key word (reserved or other) in PostgreSQL.  That listing
   tends to be accurate, because it is generated straight from the code.
   
   > The problem I have (and others may get) is porting apps from other databases
   > that support reserved words as identifiers (SQL server being the main one).
   >
   > I assume the parser should know where it is (first and follow sets would
   > define whether a reserved word is allowed or not?), so is there any reason
   > why an identifier cannot cope with reserved words?.
   
   Unfortunately, the parser is a bit more complex than what can be put in a
   few words like "knows where it is".  When you pick a particular parser
   model then you accept the technical limitations of that model.  So when
   bison/yacc says, "The way you have written your grammar I cannot process
   it" then you have to change your grammar.  One alternative is to unroll
   clauses, which is bug prone, creates maintenance problems, and bloats the
   program.  The other alternative is to restrict the use of certain key
   words.  While restricting any and every word when you're too bored to work
   harder to fix the parser is generally to be avoided, it is all the more
   acceptable if SQL actually says that the word should be reserved in
   conforming implementations.
   
   > If not, can anyone point me in the direction of the code that does the
   > parsing so I can take a look - if this would be helpful!
   
   src/backend/parser/gram.y
   
   But since the problematic word in your case is not CALL but SELECT, I can
   tell you right away with relative certainty that it will not be possible
   to change the parser to accept SELECT as an identifier in all contexts
   without butchering the grammar beyond reason.
   
   -- 
   Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/
   
   
   

4. Re: create table bug with reserved words?

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-16T17:11:34Z

   Peter Eisentraut <peter_e@gmx.net> writes:
   > But since the problematic word in your case is not CALL but SELECT, I can
   > tell you right away with relative certainty that it will not be possible
   > to change the parser to accept SELECT as an identifier in all contexts
   > without butchering the grammar beyond reason.
   
   You can drop the "without" qualifier ;-) --- it's not possible period.
   Counterexample:
   
   		SELECT (SELECT (3)) FROM foo;
   
   Is the second SELECT a (rather vacuous) sub-select, or is it a call of a
   function named SELECT?
   
   If you've got a really strong urge to use some keyword as an identifier,
   that's what double quotes are for.  But the SQL syntax does require a
   lot of keywords to be reserved.  I believe that we are actually more
   permissive in this respect than the SQL spec expects us to be.
   
   			regards, tom lane