Re: RI and PARSER (was: Re: [HACKERS] RI status report #1) - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
Date
Msg-id 37F19876.D0852A9B@alumni.caltech.edu
Whole thread Raw
In response to Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)  (wieck@debis.com (Jan Wieck))
Responses Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
List pgsql-hackers
>     Just   tell  me  which  of  these  SQL3  "reserved"  keywords
>     (according to the SQL3 draft I  got  from  Vadim)  should  be
>     available for column ID or Label:
>       CONSTRAINTS
>       DEFERRABLE
>       DEFERRED
>       IMMEDIATE
>       INITIALLY
>       PENDANT
>       RESTRICT
>     Then  I'll add them before committing. Overlooking the syntax
>     of my new commands, it wouldn't hurt to add them all to these
>     lists. But should SQL3 reserved words really be in them?

We have tried to allow as many keywords as possible for identifiers
(for ColId, which includes ColLabel) or, as a more limited choice, for
column aliases (ColLabel only). This is particularly helpful as we
implement more and more of the standard, and take away previously
allowed column and table names. The keywords, reserved, unreserved,
and unused, are documented for Postgres in syntax.sgml, and the docs
present them wrt the SQL92 and SQL3 standards.

What I usually do is try adding one or all of them to ColId, and if
that fails by giving shift/reduce conflicts I'll try moving the
offenders to ColLabel. There aren't many places in the syntax where
yacc/bison can't handle keywords at least as column labels.
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


pgsql-hackers by date:

Previous
From: Nuchanach Klinjun
Date:
Subject: Returned Result via ODBC!
Next
From: Mike Mascari
Date:
Subject: Re: [HACKERS] DROP TABLE inside transaction block