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

Chris Storah writes:

There seems to be an inconsistency in the parsing of create table (possibly
other SQL syntax?):

create table test (call int, end, int, select int);
Fails with ERROR: parser: parse error at or near "create"

SELECT is a reserved word. The error message just shows that the parser
is significantly confused.

create table test (call int, end1, int, select1 int);
Works.

Call, End and Select are reserved words, but why does 'Call' work and the
others fail?
Is this a bug - should the parser cope with any reserved words as
identifiers?

Thanks,
Chris

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

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

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

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/

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

Peter Eisentraut wrote:

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.

Just found out how MSSQL does it...it cheats!
The parser takes 'create table test (select int)' and converts it into
'create table test ([select] int)'.
I guess that this isn't an SQL92/99 compliant method :)

Thanks for the help,
Chris