Re: pl/pgsql feature request: shorthand for argument and local variable references
| От | Pavel Stehule |
|---|---|
| Тема | Re: pl/pgsql feature request: shorthand for argument and local variable references |
| Дата | |
| Msg-id | CAFj8pRAKdz5ZKRX0dmMFNRDqZTihhrzaW4V5uXOnFdd2cfMC8w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pl/pgsql feature request: shorthand for argument and local variable references (Hannu Krosing <hannuk@google.com>) |
| Список | pgsql-hackers |
pá 19. 3. 2021 v 14:14 odesílatel Hannu Krosing <hannuk@google.com> napsal:
On Thu, Mar 18, 2021 at 4:23 PM Pavel Stehule <pavel.stehule@gmail.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;
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 $$
RETURNS ... AS $$
#TOPSCOPE_LABEL fnargs
<< topblock >>
DECLARE
a int := fnargs.a * 2;
b int := topblock.a + 2;
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.
В списке pgsql-hackers по дате отправления:
Следующее
От: Stephen FrostДата:
Сообщение: Re: shared memory stats: high level design decisions: consistency, dropping