Re: plpgsql and qualified variable names

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: plpgsql and qualified variable names
Дата
Msg-id 469943C0.3010801@enterprisedb.com
обсуждение исходный текст
Ответ на plpgsql and qualified variable names  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: plpgsql and qualified variable names
Re: plpgsql and qualified variable names
Список pgsql-hackers
Tom Lane wrote:
> Anyway, I'm not writing just to point out that we have a previously
> undocumented feature.  I notice that the section on porting from Oracle
> PL/SQL mentions
> 
>   You cannot use parameter names that are the same as columns that are
>   referenced in the function. Oracle allows you to do this if you qualify
>   the parameter name using function_name.parameter_name.
> 
> While i haven't tested yet, I believe that we could match this Oracle
> behavior with about a one-line code change: the outermost namespace
> level ("block") that the function parameter aliases are put into just
> needs to be given a label equal to the function name, instead of being
> label-less as it currently is.

If I'm understanding that correctly, Oracle would resolve the reference
to "ambiguous" in the function below to column in table foo, but allows
you to reference the parameter instead by specifying
"somefunc.ambiguous", while we always resolve it to the parameter.

CREATE TABLE foo (ambiguous integer);

CREATE FUNCTION somefunc(ambiguous integer) RETURNS integer AS $$
DECLARE SELECT ambiguous FROM foo;
...

ISTM supporting "somefunc.ambiguous" just gives us another way to
reference the parameter, and there still isn't any way to refer the column.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plpgsql FOR loop doesn't guard against strange step values
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: plpgsql FOR loop doesn't guard against strange step values