Re: PL/pgSQL RENAME bug?

Started by Jan Wieckalmost 24 years ago2 messages
#1Jan Wieck
janwieck@yahoo.com

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

#2Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Jan Wieck (#1)

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