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: Noah Misch <noah@leadboat.com>
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-10T14:52:15Z
Lists: pgsql-hackers 
Noah Misch <noah@leadboat.com> writes:
> On Fri, Apr 09, 2021 at 12:09:43PM -0400, Tom Lane wrote:
>> 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:

Agreed.  But ...

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

... I'm not sure this conclusion follows.  There are two problems with it:

1. I don't see an acceptably low-overhead way to mechanize it.
Deparsing prosqlbody is unlikely to be safe in a post-error transaction,
but surely we'd not want to expend that cost in advance on every use
of a SQL function.  Even ignoring that, the act of deparsing would not
in itself tell you what offset to use.  Should we deparse and then
re-parse to get a new node tree with corrected token locations?

2. The reason we can get away with showing a fragment of a large query
(or function body) in an error message is that the user is supposed to
be able to correlate the display with what she wrote.  That assumption
falls to the ground if the display is based on a deconstruction that is
virtually certain to have line breaks in different places, not to mention
that the details of what is shown may be substantially different from the
original.

Still, I take your point that the original text may be less useful
for this purpose than I was supposing.

			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