Re: SQL-standard function body
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-30T18:13:39Z
Lists: pgsql-hackers
út 30. 6. 2020 v 19:58 odesílatel Robert Haas <robertmhaas@gmail.com> napsal: > 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. Regards Pavel > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > >
Commits
-
Don't crash on empty statements in SQL-standard function bodies.
- bfeede9fa464 14.0 landed
-
psql: Fix line continuation prompts for unbalanced parentheses
- d9a9f4b4b92a 14.0 landed
-
Provide query source text when parsing a SQL-standard function body.
- 409723365b27 14.0 landed
-
Revert "Cope with NULL query string in ExecInitParallelPlan()."
- 83efce7a1ebc 14.0 landed
-
Undo decision to allow pg_proc.prosrc to be NULL.
- 1111b2668d89 14.0 landed
-
SQL-standard function body
- e717a9a18b2e 14.0 landed
-
Move pg_stat_statements query jumbling to core.
- 5fd9dfa5f50e 14.0 cited
-
Extend SQL function tests lightly
- 11b80d900fe4 14.0 landed