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

ne 28. 3. 2021 v 16:04 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)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