Обсуждение: Parser breakage: "timestamp" has become a reserved word

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.

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

tree=> \d stringdataseriesclass

Table    = stringdataseriesclass
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| label                            | text not null                    |   var |
| timestamp                        | datetime not null                |     8 |
| value                            | text not null                    |   var |
+----------------------------------+----------------------------------+-------+

tree=> select timestamp from stringdataseriesclass;
ERROR:  parser: parse error at or near "from"

tree=> select label from stringdataseriesclass;
label
-----
(0 rows)

tree=>

            regards, tom lane

> 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

btw, you can patch the problem yourself in the meantime by adding a line
to backend/parser/gram.y:

1) in an editor, look for the line starting with "ColId"
   (near line # 4639)
2) add a line in the block of code immediately following the "ColId"
which references "timestamp" in the same way that the other lines
reference those reserved words.
3) re-install the backend (you must have bison available on your system
to rebuild the gram.y).

                       - Tom