> 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
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.
In response to
pgsql-hackers by date
|Next:||From: Frank Ridderbusch||Date: 1998-10-12 06:53:49|
|Subject: Re: [HACKERS] Minor problem with Solaris 2.7beta|
|Previous:||From: Gene Selkov Jr.||Date: 1998-10-12 06:39:14|
|Subject: Re: yet another problem in recent builds, GIST this time |