Horton

Re: SQL-standard function body

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2021-04-18T21:33:38Z
Lists: pgsql-hackers 
... BTW, a dependency loop is also possible without using this feature,
by abusing default-value expressions:

create function f1(x int, y int) returns int language sql
as 'select $1 + $2';
create function f2(x int, y int default f1(1,2)) returns int language sql
as 'select $1 + $2';
create or replace function f1(x int, y int default f2(11,12)) returns int language sql
as 'select $1 + $2';

The actual use-case for that seems pretty thin, so we never bothered
to worry about it before.  But if we're going to build loop-breaking
logic to handle function body dependencies, it should deal with this
too.  I think that all that's required is for the initial dummy
function declaration to omit defaults as well as providing a dummy
body.

			regards, tom lane

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