Re: SQL-standard function body

út 30. 6. 2020 v 19:58 odesílatel Robert Haas <robertmhaas(at)gmail(dot)com>
napsal:

> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)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.

Regards

Pavel

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>