Re: PL/pgSQL RENAME bug?
| От | Tom Lane |
|---|---|
| Тема | Re: PL/pgSQL RENAME bug? |
| Дата | |
| Msg-id | 6494.1003865487@sss.pgh.pa.us обсуждение |
| Ответ на | PL/pgSQL RENAME bug? ("Command Prompt, Inc." <pgsql-hackers@commandprompt.com>) |
| Ответы |
Re: PL/pgSQL RENAME bug?
Re: PL/pgSQL RENAME bug? Re: PL/pgSQL RENAME bug? |
| Список | pgsql-hackers |
"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...
> 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?
regards, tom lane
В списке pgsql-hackers по дате отправления: