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 CAFj8pRCMXRePJD1GviRHczRqpaNaeXhJ2ygMww4DORdATTueXw@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


ne 28. 3. 2021 v 16:04 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
On Sun, Mar 28, 2021 at 03:52:35PM +0200, Joel Jacobson wrote:
> On Sun, Mar 28, 2021, at 15:12, Pavel Stehule wrote:
> > Maybe I don't understand your proposal well, I am sorry. Creating your own language should not be hard, but in this case the plpgsql is not well extendable. The important structures are private. You can do it, but you should do a full copy of plpgsql. I don't think so you can reuse handler's routines - it is not prepared for it. Unfortunately, the handler expects only function oid and arguments, and there is not a possibility how to pass any options (if I know).
>
> Sorry, let me clarify what I mean.
>
> I mean something along the lines of adding a new nullable column to "pg_language", maybe "lanroutinelabel"?
> All other columns (lanispl, lanpltrusted, lanplcallfoid, laninline, lanvalidator) would reuse the same values as plpgsql.

It doesn't seem like a good way to handle some customization of existing
language.  It's too specialized and soon people will ask for fields to change
the default behavior of many other things and a default "routine label" may not
make sense in all languages.  If we were to do that we should probably add a
new function that would be called to setup all language specific stuff that
users may want to change.

Yes, this has a benefit just for plpgsql. I can imagine a little bit different API of plpgsql that allows more direct calls than now. For example

static PLpgSQL_function *
do_compile(FunctionCallInfo fcinfo,
<--><-->   HeapTuple procTup,
<--><-->   PLpgSQL_function *function,
<--><-->   PLpgSQL_func_hashkey *hashkey,
<--><-->   bool forValidator)
{

if the function do_compile will be public, and if there will be new argument - compile_options, then can easily force these options, and is relatively easy to reuse plpgsql as base for own language.

It can be interesting for plpgsql_check too. But I am not sure if it is too strong an argument for Tom :)

Regards

Pavel








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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Idea: Avoid JOINs by using path expressions to follow FKs
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Autovacuum worker doesn't immediately exit on postmaster death