Re: SQL-standard function body

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Jaime Casanova <jcasanov@systemguards.com.ec>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-10T03:30:14Z
Lists: pgsql-hackers
On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote:
> Finally, 0003 might be a bit controversial: it changes the stored
> prosrc for new-style SQL functions to be the query text of the CREATE
> FUNCTION command.  The main argument I can see being made against this
> is that it'll bloat the pg_proc entry.  But I think that that's
> not a terribly reasonable concern

Such storage cost should be acceptable, but ...

> The real value of 0003 of course would be to get an error cursor at
> runtime

A key benefit of $SUBJECT is the function body following DDL renames:

create table foo ();
insert into foo default values;
create function count_it() returns int begin atomic return (select count(*) from foo); end;
select count_it();
insert into foo default values;
alter table foo rename to some_new_long_table_name;
select count_it();  -- still works

After the rename, any stored prosrc is obsolete.  To show accurate error
cursors, deparse prosqlbody and use that in place of prosrc.



Commits

  1. Don't crash on empty statements in SQL-standard function bodies.

  2. psql: Fix line continuation prompts for unbalanced parentheses

  3. Provide query source text when parsing a SQL-standard function body.

  4. Revert "Cope with NULL query string in ExecInitParallelPlan()."

  5. Undo decision to allow pg_proc.prosrc to be NULL.

  6. SQL-standard function body

  7. Move pg_stat_statements query jumbling to core.

  8. Extend SQL function tests lightly