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?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PL/pgSQL RENAME bug?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PL/pgSQL RENAME bug?  (Jan Wieck <janwieck@yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: Bill Studenmund
Дата:
Сообщение: Re: schema support, was Package support for Postgres
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: schema support, was Package support for Postgres