Re: pl/pgsql feature request: shorthand for argument and local variable references - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pl/pgsql feature request: shorthand for argument and local variable references
Date
Msg-id 20210328155851.ie3nhi6bhpvepy7b@nol
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Autovacuum worker doesn't immediately exit on postmaster death
Next
From: Pavel Stehule
Date:
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references