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 CAFj8pRC15_a6HT1pY803B_Og-ymfJE0vhzeALr5ZyodEciVuOw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pl/pgsql feature request: shorthand for argument and local variable references  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: pl/pgsql feature request: shorthand for argument and local variable references  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers


čt 6. 1. 2022 v 8:02 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
Hi Pavel,

On Wed, Mar 24, 2021 at 08:09:13AM +0100, Pavel Stehule wrote:
>
> I am continuing to  talk with Hannu about syntax. I think so using the
> compile option is a good direction, but maybe renaming from "routine_label"
> to "topscope_label" (proposed by Hannu) or maybe "outerscope_label" can be
> a good idea.

It's not clear to me what is the status of this patch.  You sent some updated
patch since with some typo fixes but I don't see any conclusion about the
direction this patch should go and/or how to name the new option.

Should the patch be reviewed or switched to Waiting on Author?

I am not sure if there is enough agreement and if there is enough necessity for this feature.

In this discussion there were more general questions about future development of plpgsql (about possible configurations and compiler parametrizations, and how to switch the configuration on global and on local levels). This is not fully solved yet. This is probably the reason why discussion about this specific feature (and very simple feature) has not reached a clear end. Generally, this is the same problem in Postgres.

Personally, I don't want to write a complicated patch for this relatively trivial (and not too important feature). Sure, then it cannot solve more general questions. I think the plpgsql option can work well - maybe with the keyword "top_label" or "root_label". Probably some enhancing of the DECLARE statement can work too (if it will be done well). But it requires more work, because the DECLARE statement has block scope, and then the alias of the top label has to have block scope too. Theoretically we can propagate it to GUC too - same like plpgsql.variable_conflict. This simple design can work (my opinion), but I understand so it is not a general reply for people who can have more control over the behavior of plpgsql. But I think it is a different issue and should be solved separately (and this pretty complex problem, because Postgres together with PLpgSQL mix different access models - access rights, searching path, local scope, and we miss possible parametrization on schema level what has most sense for PLpgSQL).

Regards

Pavel







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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Support tab completion for upper character inputs in psql
Следующее
От: SATYANARAYANA NARLAPURAM
Дата:
Сообщение: Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers