Thread: Declaring a field that is also an out parameter in a function
In the following short code, the out parameter d3 is also declared, so
its value will be null in the output.
create or replace function public.test_function(in varchar, in char, in date, ou
t d1 text, out d2 integer, out d3 char, out d4 date )
stable as $$
DECLARE
wk_intxt alias for $1;
wk_inchar alias for $2;
wk_indate alias for $3;
d3 char;
BEGIN
d1 := 'foo,bar';
d2 := 15;
d3 := 'X';
d4 := current_date;
END
$$ language 'plpgsql';
Here's what happens in 16.1:
psql (16.1)
Type "help" for help.
uscf=> select test_function('1234','a','2024-01-01')
uscf-> \g
test_function
----------------------------
("foo,bar",15,,2024-07-06)
(1 row)
Shouldn't declaring a field that is also an OUT parameter throw an error?
Mike Nolan
htfoot@gmail.com
Michael Nolan <htfoot@gmail.com> writes:
> Shouldn't declaring a field that is also an OUT parameter throw an error?
No. The DECLARE is a block nested within the function,
and the parameter is declared at function scope.
So this is a standard case of an inner declaration masking
an outer one.
Possibly plpgsql_check can be set to complain about such cases,
but they're legal according to the language specification.
regards, tom lane
ne 7. 7. 2024 v 0:14 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Michael Nolan <htfoot@gmail.com> writes:
> Shouldn't declaring a field that is also an OUT parameter throw an error?
No. The DECLARE is a block nested within the function,
and the parameter is declared at function scope.
So this is a standard case of an inner declaration masking
an outer one.
Possibly plpgsql_check can be set to complain about such cases,
but they're legal according to the language specification.
yes, it does
(2024-07-07 09:27:14) postgres=# select * from plpgsql_check_function('test_function');
┌───────────────────────────────────────────────────────────────┐
│ plpgsql_check_function │
╞═══════════════════════════════════════════════════════════════╡
│ warning:00000:10:statement block:parameter "d3" is overlapped │
│ Detail: Local variable overlap function parameter. │
│ warning extra:00000:8:DECLARE:never read variable "d3" │
│ warning extra:00000:unused parameter "$1" │
│ warning extra:00000:unused parameter "$2" │
│ warning extra:00000:unused parameter "$3" │
│ warning extra:00000:unmodified OUT variable "d3" │
└───────────────────────────────────────────────────────────────┘
(7 rows)
┌───────────────────────────────────────────────────────────────┐
│ plpgsql_check_function │
╞═══════════════════════════════════════════════════════════════╡
│ warning:00000:10:statement block:parameter "d3" is overlapped │
│ Detail: Local variable overlap function parameter. │
│ warning extra:00000:8:DECLARE:never read variable "d3" │
│ warning extra:00000:unused parameter "$1" │
│ warning extra:00000:unused parameter "$2" │
│ warning extra:00000:unused parameter "$3" │
│ warning extra:00000:unmodified OUT variable "d3" │
└───────────────────────────────────────────────────────────────┘
(7 rows)
but looks so there are false alarms related to using an alias. It is interesting so I have not any report about this issue, so probably using aliases is not too common today.
Regards
Pavel
regards, tom lane
ne 7. 7. 2024 v 9:31 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
ne 7. 7. 2024 v 0:14 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:Michael Nolan <htfoot@gmail.com> writes:
> Shouldn't declaring a field that is also an OUT parameter throw an error?
No. The DECLARE is a block nested within the function,
and the parameter is declared at function scope.
So this is a standard case of an inner declaration masking
an outer one.
Possibly plpgsql_check can be set to complain about such cases,
but they're legal according to the language specification.yes, it does(2024-07-07 09:27:14) postgres=# select * from plpgsql_check_function('test_function');
┌───────────────────────────────────────────────────────────────┐
│ plpgsql_check_function │
╞═══════════════════════════════════════════════════════════════╡
│ warning:00000:10:statement block:parameter "d3" is overlapped │
│ Detail: Local variable overlap function parameter. │
│ warning extra:00000:8:DECLARE:never read variable "d3" │
│ warning extra:00000:unused parameter "$1" │
│ warning extra:00000:unused parameter "$2" │
│ warning extra:00000:unused parameter "$3" │
│ warning extra:00000:unmodified OUT variable "d3" │
└───────────────────────────────────────────────────────────────┘
(7 rows)but looks so there are false alarms related to using an alias. It is interesting so I have not any report about this issue, so probably using aliases is not too common today.
I was blind, plpgsql_check is correct
Regards
Pavel
RegardsPavel
regards, tom lane
On Sun, Jul 7, 2024 at 4:13 AM Pavel Stehule <pavel.stehule@gmail.com> wrote: > > but looks so there are false alarms related to using an alias. It is interesting so I have not any report about this issue,so probably using aliases is not too common today. I'm not sure why there's a warning about using an alias. 43.3.1 says to use them for improved readability. Mike Nolan
Pavel Stehule <pavel.stehule@gmail.com> writes:
> (2024-07-07 09:27:14) postgres=# select * from
> plpgsql_check_function('test_function');
> ┌───────────────────────────────────────────────────────────────┐
> │ plpgsql_check_function │
> ╞═══════════════════════════════════════════════════════════════╡
> │ warning:00000:10:statement block:parameter "d3" is overlapped │
> │ Detail: Local variable overlap function parameter. │
Nice! FWIW, I think the standard terminology is "local variable
shadows function parameter".
regards, tom lane
ne 7. 7. 2024 v 15:01 odesílatel Michael Nolan <htfoot@gmail.com> napsal:
On Sun, Jul 7, 2024 at 4:13 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> but looks so there are false alarms related to using an alias. It is interesting so I have not any report about this issue, so probably using aliases is not too common today.
I'm not sure why there's a warning about using an alias. 43.3.1 says
to use them for improved readability.
it is obsolete - aliases were used when Postgres doesn't support named arguments.
I don't know any good reason why one variable can use more than one name.
There can be an exception when argument names are very long, but generally they are not used.
Mike Nolan
On Sunday, July 7, 2024, Michael Nolan <htfoot@gmail.com> wrote:
On Sun, Jul 7, 2024 at 4:13 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> but looks so there are false alarms related to using an alias. It is interesting so I have not any report about this issue, so probably using aliases is not too common today.
I'm not sure why there's a warning about using an alias. 43.3.1 says
to use them for improved readability.
Mostly because you should just name variables correctly the first time. It improves readability if you use $n parameter names, which you should not. As noted in 43.3.2, sometimes you don’t have a choice, though new and old aren’t usually problematic enough to warrant aliasing.
David J.
On 7/7/24 07:42, Pavel Stehule wrote: > I'm not sure why there's a warning about using an alias. 43.3.1 says > to use them for improved readability. > > > it is obsolete - aliases were used when Postgres doesn't support named > arguments. Is that was what it was complaining about or the fact they where declared and never used? > > I don't know any good reason why one variable can use more than one name. Section 43.3.2. ALIAS provides the pros/cons. > > There can be an exception when argument names are very long, but > generally they are not used. > > > > Mike Nolan > -- Adrian Klaver adrian.klaver@aklaver.com
ne 7. 7. 2024 v 16:48 odesílatel Adrian Klaver <adrian.klaver@aklaver.com> napsal:
On 7/7/24 07:42, Pavel Stehule wrote:
> I'm not sure why there's a warning about using an alias. 43.3.1 says
> to use them for improved readability.
>
>
> it is obsolete - aliases were used when Postgres doesn't support named
> arguments.
Is that was what it was complaining about or the fact they where
declared and never used?
I am not sure if I understand the question. My reply was related to generic usage of aliases.
Report from plpgsql_check was correct - and related variables were not used.
>
> I don't know any good reason why one variable can use more than one name.
Section 43.3.2. ALIAS provides the pros/cons.
>
> There can be an exception when argument names are very long, but
> generally they are not used.
>
>
>
> Mike Nolan
>
--
Adrian Klaver
adrian.klaver@aklaver.com
ne 7. 7. 2024 v 16:37 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> (2024-07-07 09:27:14) postgres=# select * from
> plpgsql_check_function('test_function');
> ┌───────────────────────────────────────────────────────────────┐
> │ plpgsql_check_function │
> ╞═══════════════════════════════════════════════════════════════╡
> │ warning:00000:10:statement block:parameter "d3" is overlapped │
> │ Detail: Local variable overlap function parameter. │
Nice! FWIW, I think the standard terminology is "local variable
shadows function parameter".
fixed
regards, tom lane
On 7/7/24 07:53, Pavel Stehule wrote: > > > ne 7. 7. 2024 v 16:48 odesílatel Adrian Klaver > <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> napsal: > > On 7/7/24 07:42, Pavel Stehule wrote: > > I'm not sure why there's a warning about using an alias. > 43.3.1 says > > to use them for improved readability. > > > > > > it is obsolete - aliases were used when Postgres doesn't support > named > > arguments. > > Is that was what it was complaining about or the fact they where > declared and never used? > > > I am not sure if I understand the question. My reply was related to > generic usage of aliases. The conversation was: Mike Nolan "I'm not sure why there's a warning about using an alias. 43.3.1 says to use them for improved readability." Pavel Stehule "it is obsolete - aliases were used when Postgres doesn't support named arguments." I was just trying to confirm that the warning was not for ALIAS being declared. That it was for what you state below. > > Report from plpgsql_check was correct - and related variables were not > used. > > > > > > I don't know any good reason why one variable can use more than > one name. > > Section 43.3.2. ALIAS provides the pros/cons. > > > > > There can be an exception when argument names are very long, but > > generally they are not used. > > > > > > > > Mike Nolan > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com> > -- Adrian Klaver adrian.klaver@aklaver.com
ne 7. 7. 2024 v 17:00 odesílatel Adrian Klaver <adrian.klaver@aklaver.com> napsal:
On 7/7/24 07:53, Pavel Stehule wrote:
>
>
> ne 7. 7. 2024 v 16:48 odesílatel Adrian Klaver
> <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> napsal:
>
> On 7/7/24 07:42, Pavel Stehule wrote:
> > I'm not sure why there's a warning about using an alias.
> 43.3.1 says
> > to use them for improved readability.
> >
> >
> > it is obsolete - aliases were used when Postgres doesn't support
> named
> > arguments.
>
> Is that was what it was complaining about or the fact they where
> declared and never used?
>
>
> I am not sure if I understand the question. My reply was related to
> generic usage of aliases.
The conversation was:
Mike Nolan
"I'm not sure why there's a warning about using an alias. 43.3.1 says
to use them for improved readability."
Pavel Stehule
"it is obsolete - aliases were used when Postgres doesn't support named
arguments."
I was just trying to confirm that the warning was not for ALIAS being
declared. That it was for what you state below.
ok
>
> Report from plpgsql_check was correct - and related variables were not
> used.
>
>
> >
> > I don't know any good reason why one variable can use more than
> one name.
>
> Section 43.3.2. ALIAS provides the pros/cons.
>
> >
> > There can be an exception when argument names are very long, but
> > generally they are not used.
> >
> >
> >
> > Mike Nolan
> >
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
--
Adrian Klaver
adrian.klaver@aklaver.com