| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | Joel Jacobson <joel(at)compiler(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pl/pgsql feature request: shorthand for argument and local variable references |
| Date: | 2021-03-28 16:00:55 |
| Message-ID: | CAFj8pRCX5pscweR=Sid0eqiCaFT8MRLPS+0xdECnU=6rvnNuVg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
ne 28. 3. 2021 v 17:58 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)com>
napsal:
> On Sun, Mar 28, 2021 at 05:12:10PM +0200, Pavel Stehule wrote:
> >
> > 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 :)
>
> I think that it would be sensible to do something along those lines.
> Especially if it allows better static analysis for tools like
> plpgsql_check.
> But that's definitely out of this patch's scope, and not pg14 material.
>
yes, sure.
Pavel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2021-03-28 17:22:16 | Re: Add docs stub for recovery.conf |
| Previous Message | Julien Rouhaud | 2021-03-28 15:58:51 | Re: pl/pgsql feature request: shorthand for argument and local variable references |