Thread

1. 6.4 and reserved word USER...

   Michael J Schout <mschout@gkg.net> — 1998-10-29T03:51:48Z

   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
   
   

2. Re: [HACKERS] 6.4 and reserved word USER...

   Marc G. Fournier <scrappy@hub.org> — 1998-10-29T04:37:22Z

   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 
   
   
   

3. Re: [HACKERS] 6.4 and reserved word USER...

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-29T05:33:00Z

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