On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > This adds support for writing CREATE FUNCTION and CREATE PROCEDURE > statements for language SQL with a function body that conforms to the > SQL standard and is portable to other implementations.
With what other implementations is it compatible?
> The function body is parsed at function definition time and stored as > expression nodes in probin. So at run time, no further parsing is > required. > > However, this form does not support polymorphic arguments, because > there is no more parse analysis done at call time. > > Dependencies between the function and the objects it uses are fully > tracked. > > A new RETURN statement is introduced. This can only be used inside > function bodies. Internally, it is treated much like a SELECT > statement. > > psql needs some new intelligence to keep track of function body > boundaries so that it doesn't send off statements when it sees > semicolons that are inside a function body. > > Also, per SQL standard, LANGUAGE SQL is the default, so it does not > need to be specified anymore.
Hmm, this all seems like a pretty big semantic change. IIUC, right now, a SQL function can only contain one statement, but it seems like with this patch you can have a block in there with a bunch of statements, sorta like plpgsql. But probably you don't have all of the functionality of plpgsql available. Also, the fact that you're doing parsing earlier means that e.g. creating a table and inserting into it won't work. Maybe that's fine. But it almost seems like you are inventing a whole new PL....
It is SQL/PSM and can be nice to have it.
I am a little bit afraid about performance - SQL functions doesn't use plan cache and simple expressions. Without inlining it can be too slow.