Re: [HACKERS] Parser breakage: "timestamp" has become a reserved word

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Parser breakage: "timestamp" has become a reserved word
Date: 1998-10-12 06:53:11
Message-ID: 3621A757.5658229C@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Frank Ridderbusch 1998-10-12 06:53:49 Re: [HACKERS] Minor problem with Solaris 2.7beta
Previous Message Gene Selkov Jr. 1998-10-12 06:39:14 Re: yet another problem in recent builds, GIST this time