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/
