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: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-07-01T16:50:24Z
Lists: pgsql-hackers 
Bruce Momjian <bruce@momjian.us> writes:
> Is the SQL-standard function body verified as preventing function
> inlining?  That seems to be a major downside.

I see no reason why that would make any difference.  There might
be more code to be written than is in the patch, but in principle
inlining should not care whether the function is pre-parsed or not.

			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