Thread: 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
Re: [HACKERS] Parser breakage: "timestamp" has become a reserved word
From
"Thomas G. Lockhart"
Date:
> 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
Re: [HACKERS] Parser breakage: "timestamp" has become a reserved word
From
"Thomas G. Lockhart"
Date:
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