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 CAFj8pRAPiPn97nMgnzbDCu_4pU-QreXLhNY7F=b3OUVS6gABCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pl/pgsql feature request: shorthand for argument and local variable references  (Hannu Krosing <hannuk@google.com>)
Список pgsql-hackers


čt 18. 3. 2021 v 15:49 odesílatel Hannu Krosing <hannuk@google.com> napsal:
I went to archives and read the whole discussion for this from the beginning

I did not really understand, why using the ALIAS FOR syntax is significantly
harder to implement then #routine_label

just because it can be used in different places - for example in nested blocks. And then you need to create really new aliases for these object in current namespace. And it is not easy because we cannot to iterate in ns_items tree from root



The things you mentioned as currently using #OPTION seem to be in a different
category from the aliases and block labels - they are more like pragmas -  so to
me it still feels inconsistent to use #routine_label for renaming the
outer namespace.

I think this feature allows for more concepts.




Also checked code and indeed there is support for #OPTION DUMP and
#VARIABLE_CONFLICT ERROR
Is it documented and just hard to find ?

please, see my previous mail. There was links

On Thu, Mar 18, 2021 at 3:19 PM Hannu Krosing <hannuk@google.com> wrote:
>
> On Thu, Mar 18, 2021 at 5:27 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >
> >
> > There are few main reasons:
> >
> > a) compile options are available already - so I don't need invent new syntax - #OPTION DUMP, #PRINT_STRICT ON, #VARIABLE_CONFLICT ERROR
>
> Are these documented anywhere ?
>
> At least a quick search for pl/pgsql + #OPTION DUMP, #PRINT_STRICT ON,
> #VARIABLE_CONFLICT ERROR returned nothing relevant and also searching
> in
>
> If pl/pgsql actually supports any of these, these should get documented!
>
>
>
> For me the most logical place for declaring a function name alias
> would be to allow  ALIAS FOR the function name in DECLARE section.
>
> plpgsql_test=# CREATE FUNCTION
> a_function_with_an_inconveniently_long_name(i int , OUT o int)
> LANGUAGE plpgsql AS $plpgsql$
> DECLARE
>    fnarg ALIAS FOR a_function_with_an_inconveniently_long_name;
> BEGIN
>    fnarg.o = 2 * fnarg.i;
> END;
> $plpgsql$;
>
> but unfortunately this currently returns
>
> ERROR:  42704: variable "a_function_with_an_inconveniently_long_name"
> does not exist
> LINE 4:    fnarg ALIAS FOR a_function_with_an_inconveniently_long_na...
>                            ^
> LOCATION:  plpgsql_yyparse, pl_gram.y:677
>
> Variation could be
>
> DECLARE
>    fnarg ALIAS FOR FUNCTION a_function_with_an_inconveniently_long_name;
>
> so it is clear that we are aliasing current function name
>
> or even make the function name optional, as there can only be one, so
>
> DECLARE
>    fnarg ALIAS FOR FUNCTION;
>
>
> Cheers
> Hannu

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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: pl/pgsql feature request: shorthand for argument and local variable references
Следующее
От: David Steele
Дата:
Сообщение: Re: Reduce the time required for a database recovery from archive.