Bruce Momjian wrote:

    Digging  into  it  now,  I  remember  why it is there. In the
    Oracle world, someone can declare a trigger  that  references
    to NEW or OLD by other names. This RENAME was a workaround so
    one doesn't need to change the whole trigger body,  but  just
    adds a line in the DECLARE section doing the job.

    Therefore, I think removal is not such a good idea. Fixing it
    properly will take a little longer as I am a little  busy  at
    the moment.


Jan

> Jan, seems no one has commented on this.  Patch?
>
> Jan Wieck wrote:
> > Tom Lane wrote:
> > > "Command Prompt, Inc." <pgsql-hackers@commandprompt.com> writes:
> > > > Mainly, the existing documentation on the RENAME statement seems
> > > > inaccurate; it states that you can re-name variables, records, or
> > > > rowtypes. However, in practice, our tests show that attempting to RENAME
> > > > valid variables with:
> > > >   RENAME varname TO newname;
> > > > ...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax
> > > > on a non-declared variable, it actually says "there is no variable" with
> > > > that name in the current block, so...I think something odd is happening. :)
> > >
> > > Yup, this is a bug.  The plpgsql grammar expects varname to be a T_WORD,
> > > but in fact the scanner will only return T_WORD for a name that is not
> > > any known variable name.  Thus RENAME cannot possibly work, and probably
> > > never has worked.
> > >
> > > Looks like it should accept T_VARIABLE, T_RECORD, T_ROW (at least).
> > > T_WORD ought to draw "no such variable".  Jan, I think this is your turf...
> >
> >     Sounds pretty much like that. Will take a look.
> >
> > >
> > > > The RENAME statement seems kind of odd, since it seems that you could just
> > > > as easily declare a general variable with the right name to begin with,
> > >
> > > It seems pretty useless to me too.  Perhaps it's there because Oracle
> > > has one?
> >
> >     And  I  don't even remember why I've put it in. Maybe because
> >     it's an Oracle thing. This would be a cool fix, removing  the
> >     damned thing completely. I like that solution :-)
> >
> >     Anyone against removal?
> >
> >
> > Jan
> >
> > --
> >
> > #======================================================================#
> > # It's easier to get forgiveness for being wrong than for being right. #
> > # Let's break this rule - forgive me.                                  #
> > #================================================== JanWieck@Yahoo.com #
> >
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>


--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Wed, 13 Mar 2002 09:59:21 -0500 (EST)
Jan Wieck <janwieck@yahoo.com>
Re: PL/pgSQL RENAME bug?

Added to TODO:

        o Fix PL/pgSQL RENAME to work on on variable names


---------------------------------------------------------------------------

Jan Wieck wrote:
> Bruce Momjian wrote:
> 
>     Digging  into  it  now,  I  remember  why it is there. In the
>     Oracle world, someone can declare a trigger  that  references
>     to NEW or OLD by other names. This RENAME was a workaround so
>     one doesn't need to change the whole trigger body,  but  just
>     adds a line in the DECLARE section doing the job.
> 
>     Therefore, I think removal is not such a good idea. Fixing it
>     properly will take a little longer as I am a little  busy  at
>     the moment.
> 
> 
> Jan
> 
> > Jan, seems no one has commented on this.  Patch?
> >
> > Jan Wieck wrote:
> > > Tom Lane wrote:
> > > > "Command Prompt, Inc." <pgsql-hackers@commandprompt.com> writes:
> > > > > Mainly, the existing documentation on the RENAME statement seems
> > > > > inaccurate; it states that you can re-name variables, records, or
> > > > > rowtypes. However, in practice, our tests show that attempting to RENAME
> > > > > valid variables with:
> > > > >   RENAME varname TO newname;
> > > > > ...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax
> > > > > on a non-declared variable, it actually says "there is no variable" with
> > > > > that name in the current block, so...I think something odd is happening. :)
> > > >
> > > > Yup, this is a bug.  The plpgsql grammar expects varname to be a T_WORD,
> > > > but in fact the scanner will only return T_WORD for a name that is not
> > > > any known variable name.  Thus RENAME cannot possibly work, and probably
> > > > never has worked.
> > > >
> > > > Looks like it should accept T_VARIABLE, T_RECORD, T_ROW (at least).
> > > > T_WORD ought to draw "no such variable".  Jan, I think this is your turf...
> > >
> > >     Sounds pretty much like that. Will take a look.
> > >
> > > >
> > > > > The RENAME statement seems kind of odd, since it seems that you could just
> > > > > as easily declare a general variable with the right name to begin with,
> > > >
> > > > It seems pretty useless to me too.  Perhaps it's there because Oracle
> > > > has one?
> > >
> > >     And  I  don't even remember why I've put it in. Maybe because
> > >     it's an Oracle thing. This would be a cool fix, removing  the
> > >     damned thing completely. I like that solution :-)
> > >
> > >     Anyone against removal?
> > >
> > >
> > > Jan
> > >
> > > --
> > >
> > > #======================================================================#
> > > # It's easier to get forgiveness for being wrong than for being right. #
> > > # Let's break this rule - forgive me.                                  #
> > > #================================================== JanWieck@Yahoo.com #
> > >
> > >
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 5: Have you checked our extensive FAQ?
> > >
> > > http://www.postgresql.org/users-lounge/docs/faq.html
> > >
> >
> > --
> >   Bruce Momjian                        |  http://candle.pha.pa.us
> >   pgman@candle.pha.pa.us               |  (610) 853-3000
> >   +  If your life is a hard drive,     |  830 Blythe Avenue
> >   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> >
> 
> 
> --
> 
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #================================================== JanWieck@Yahoo.com #
> 
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 8 Apr 2002 23:55:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: PL/pgSQL RENAME bug?