Thread: 6.4 and reserved word USER...

Hi.

I have not followed hackers regularly, so im sure this has probably been 
asked before.  Anyways, I tried the 6.4 beta 3 today, and noticed that
the
word "USER" has been reserved now.  Since I have an app that uses a
column
named "user" I went into backend/parser/gram.y and added a line like:
    | USER          { $$ = "user" }

into that file so that USER would be accepted.

However, I noticed that this breaks a lot of queries :).  Apparently
doing a
"SELECT user" now returns your username.  So in order to make my queries
work
I would have to do "SELECT table.user FROM table....".  If there is no
other
way around it, Ill probably just have to rename the colunm and track
down all
references to it in my application (ugh :().  

SO my question is this:  Is there anything else that could  be done to
make
this work?  Or will we break the "SELECT USER" usefulness by doing
something 
like this?  Im guessing its probably not going to be possible :)  But
though
I would ask those a little more familiar with the source tree than me
since
I just started looking at at now :)

Mike

Didn't we make that change for v6.3.2? *raised eyebrow*

On Wed, 28 Oct 1998, Michael J Schout wrote:

> Hi.
> 
> I have not followed hackers regularly, so im sure this has probably been 
> asked before.  Anyways, I tried the 6.4 beta 3 today, and noticed that
> the
> word "USER" has been reserved now.  Since I have an app that uses a
> column
> named "user" I went into backend/parser/gram.y and added a line like:
> 
>      | USER          { $$ = "user" }
> 
> into that file so that USER would be accepted.
> 
> However, I noticed that this breaks a lot of queries :).  Apparently
> doing a
> "SELECT user" now returns your username.  So in order to make my queries
> work
> I would have to do "SELECT table.user FROM table....".  If there is no
> other
> way around it, Ill probably just have to rename the colunm and track
> down all
> references to it in my application (ugh :().  
> 
> SO my question is this:  Is there anything else that could  be done to
> make
> this work?  Or will we break the "SELECT USER" usefulness by doing
> something 
> like this?  Im guessing its probably not going to be possible :)  But
> though
> I would ask those a little more familiar with the source tree than me
> since
> I just started looking at at now :)
> 
> Mike
> 

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> > 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