Re: pl/pgsql feature request: shorthand for argument and local variable references

pá 19. 3. 2021 v 14:14 odesílatel Hannu Krosing <hannuk(at)google(dot)com> napsal:

> On Thu, Mar 18, 2021 at 4:23 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
> > But we don't support this feature. We are changing just a top scope's
> label. So syntax "ALIAS FOR FUNCTION is not good. The user can have false
> hopes
>
> In this case it looks like it should go together with other labels and
> have << label_here >> syntax ?
>
> And we are back to the question of where to put this top scope label :)
>
> Maybe we cloud still pull in the function arguments into the outermost
> blocks scope, and advise users to have an extra block if they want to
> have same names in both ?
>
>
> CREATE OR REPLACE FUNCTION fx(a int, b int)
> RETURNS ... AS $$
> << fnargs >>
> BEGIN
> << topblock >>
> DECLARE
> a int := fnargs.a * 2;
> b int := topblock.a + 2;
> BEGIN
> ....
> END;
> END;
> $$;
>

It looks pretty messy.

> and we could make the empty outer block optional and treat two
> consecutive labels as top scope label and outermost block label
>
> CREATE OR REPLACE FUNCTION fx(a int, b int)
> RETURNS ... AS $$
> << fnargs >>
> << topblock >>
> DECLARE
> a int := fnargs.a * 2;
> b int := topblock.a + 2;
> BEGIN
> ....
> END;
> $$;
>
> But I agree that this is also not ideal.
>

I agree with you :). The problem is in semantics - top outer namespace is
external - is not visible, and so placing some label anywhere in code
should to looks scary

>
> And
>
> CREATE OR REPLACE FUNCTION fx(a int, b int)
> WITH (TOPSCOPE_LABEL fnargs)
> RETURNS ... AS $$
> << topblock >>
> DECLARE
> a int := fnargs.a * 2;
> b int := topblock.a + 2;
> BEGIN
> ....
> END;
> $$;
>

> Is even more inconsistent than #option syntax
>

yes. This syntax has sense. But this syntax should be implemented from zero
(although it will be only a few lines, and then it is not a big issue).

Bigger issue is a risk of confusion with the "WITH ()" clause of CREATE
TABLE, because syntax is exactly the same, but it holds a list of GUC
settings. And it does exactly what compile options does.

CREATE TABLE foo(...) WITH (autovacuum off)

Please try to compare:

CREATE OR REPLACE FUNCTION fx(a int, b int)
WITH (TOPSCOPE_LABEL fnargs)
RETURNS ... AS $$
<< topblock >>
DECLARE
a int := fnargs.a * 2;
b int := topblock.a + 2;

CREATE OR REPLACE FUNCTION fx(a int, b int)
RETURNS ... AS $$
#TOPSCOPE_LABEL fnargs
<< topblock >>
DECLARE
a int := fnargs.a * 2;
b int := topblock.a + 2;

I don't see too big a difference, and with the compile option, I don't need
to introduce new possibly confusing syntax. If we want to implement your
proposed syntax, then we should support all plpgsql compile options there
too (for consistency). The syntax that you propose has logic. But I am
afraid about possible confusion with the same clause with different
semantics of other DDL commands, and then I am not sure if cost is adequate
to benefit.

Regards

Pavel

>
> Cheers
> Hannu
>
> PS:
>
> >
> > For cleanness/orthogonality I would also prefer the blocklables to be in
> DECLARE
> > for each block, but this train has already left :)
> > Though we probably could add alternative syntax ALIAS FOR BLOCK ?
>
> >
> > why? Is it a joke?
> >
> > you are defining a block label, and you want to in the same block
> redefine some outer label? I don't think it is a good idea.
>