From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Michael J Schout <mschout(at)gkg(dot)net> |
Cc: | The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] 6.4 and reserved word USER... |
Date: | 1998-10-29 05:33:00 |
Message-ID: | 3637FE0C.B494C7F6@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > the word "USER" has been reserved now.
> > SO my question is this: Is there anything else that could be done
> > to make this work?
Not that this helps you much, "USER" is an SQL92 reserved word. There is
a new chapter in the User's Guide on syntax which shows lists of the
reserved and unreserved words in SQL92, SQL3, and/or Postgres to help
people avoid trouble.
You can do your queries like
SELECT "user" from table...
to keep using that column name, but it would still require you to find
and change all of the instances in your apps. I assume that adding the
ColId definition of USER in gram.y resulted in massive numbers of
shift/reduce conflicts? If not, then we should just put it in there, but
I can't see why you wouldn't get the shift/reduce problems since it
would be allowed the same places as CURRENT_USER/USER are.
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1998-10-29 05:36:31 | Re: [HACKERS] Another bug in pg_operator.h |
Previous Message | Tom Lane | 1998-10-29 05:26:47 | Post-mortem: Another bug in pg_operator.h |