Horton

Re: SQL-standard function body

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2021-05-10T14:41:58Z
Lists: pgsql-hackers 
On 27.04.21 18:16, Tom Lane wrote:
> That's kind of a lot of complication, and inefficiency, for a corner case
> that may never arise in practice.  We've ignored the risk for default
> expressions, and AFAIR have yet to receive any field complaints about it.
> So maybe it's okay to do the same for SQL-style function bodies, at least
> for now.
> 
>> Another option would be that we disallow this at creation time.
> 
> Don't like that one much.  The backend shouldn't be in the business
> of rejecting valid commands just because pg_dump might be unable
> to cope later.

Since this is listed as an open item, I want to clarify that I'm 
currently not planning to work on this, based on this discussion. 
Certainly something to look into sometime later, but it's not in my 
plans right now.

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