Re: SQL-standard function body

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Julien Rouhaud <rjuju123@gmail.com>, Jaime Casanova <jcasanov@systemguards.com.ec>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-08T05:16:02Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
>> Buildfarm suggests this has some issues under force_parallel_mode.
>> I'm wondering about missed fields in outfuncs/readfuncs, or the like.

> The problem looks a bit more fundamental to me, as there seems to be
> some confusion with the concept of what should be the query string 
> when it comes to prosqlbody with a parallel run, as it replaces prosrc
> in some cases where the function uses SQL as language.  If the
> buildfarm cannot be put back to green, could it be possible to revert
> this patch?

Andres pushed a stopgap fix.  We might end up reverting the patch
altogether for v14, but I don't want to be hasty.  This should be enough
to let people take advantage of the last few hours before feature freeze.

			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