Re: [HACKERS] Parser breakage: "timestamp" has become a reserved word - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] Parser breakage: "timestamp" has become a reserved word
Date
Msg-id 3621A757.5658229C@alumni.caltech.edu
Whole thread Raw
In response to Parser breakage: "timestamp" has become a reserved word  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The current (as of 8 Oct) parser will not let me select a field named
> "timestamp" from a table.  It worked just fine a week or so ago.
> I presume the problem is that timestamp is also a data type name.

That worked just fine, but declaring a field

  TIMESTAMP WITH TIME ZONE

did not, even though I had thought I'd implemented it quite a while ago.
Apparently the declaration for TIMESTAMP in keywords.c didn't make it
into the code, even though it was a token declared in gram.y.

TIMESTAMP needed to be a key word declared in the parser since it
appears in a multi-word phrase in SQL92.

> Is this a bug, or can I expect that addition of data types may break
> tables that used to work?

In principle you can expect that using an SQL92 reserved word for a
column name will lead to trouble and grief, or at least portability
problems ;)

But it looks like gram.y will allow TIMESTAMP as a column name, so I'll
put it into the code soon (the next day or so).

The new docs have several lists of key words, reserved and unreserved,
and how they relate to Postgres, SQL92, and SQL3. Hopefully that will
help, if one reads the docs. Most people who know what they are doing
don't do much reading, so I don't know if it will help much.

                       - Tom

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] postmaster locking issues.
Next
From: Frank Ridderbusch
Date:
Subject: Re: [HACKERS] Minor problem with Solaris 2.7beta