Re: plpgsql and qualified variable names - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: plpgsql and qualified variable names
Date
Msg-id 469943C0.3010801@enterprisedb.com
Whole thread Raw
In response to plpgsql and qualified variable names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plpgsql and qualified variable names  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: plpgsql and qualified variable names  ("Affan Salman" <affan@enterprisedb.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: plpgsql FOR loop doesn't guard against strange step values
Next
From: Andrew Dunstan
Date:
Subject: Re: plpgsql FOR loop doesn't guard against strange step values