From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Jaime Casanova <jcasanov@systemguards.com.ec>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: SQL-standard function body
Date: Sat, 10 Apr 2021 13:03:26 -0700
Message-ID: <20210410200326.GD978274@rfd.leadboat.com> (raw)
In-Reply-To: <2298215.1618066335@sss.pgh.pa.us>
References: <YG54YggzyPrTFE+e@paquier.xyz>
<1819824.1617858962@sss.pgh.pa.us>
<20210408052759.7bmyawm4djnrux6y@alap3.anarazel.de>
<1820954.1617860500@sss.pgh.pa.us>
<20210408063514.houn2s3yxcorukdf@alap3.anarazel.de>
<YG620HiF8Huz/YIn@paquier.xyz>
<20210408111121.lsh6cvwjgk6ku7m5@nol>
<2197698.1617984583@sss.pgh.pa.us>
<20210410033014.GA993491@rfd.leadboat.com>
<2298215.1618066335@sss.pgh.pa.us>
On Sat, Apr 10, 2021 at 10:52:15AM -0400, Tom Lane wrote:
> 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?
If you really want those error cursors, yes. (I feel we can continue to live
without them; their absence is no more important than it was ten years ago.)
One can envision several ways to cache that high-overhead work. Otherwise,
the usual PostgreSQL answer would be to omit an error cursor, not show one
that reflects an obsolete sense of the function.
If the original CREATE FUNCTION query text were so valuable, I'd be arguing to
preserve it across dump/reload.
> 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.
Preferences on this matter will be situation-dependent. If I do CREATE
FUNCTION f() ...; SELECT f() all in one sitting, then it's fine for an error
in the SELECT to show the function I wrote. If I'm calling a function defined
years ago, I'm likely to compare the error report to "\sf foo" and not likely
to compare it to a years-old record of the SQL statement. I think it's fine
to expect users to consult "\sf foo" when the user is in doubt.
> Still, I take your point that the original text may be less useful
> for this purpose than I was supposing.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, tgl@sss.pgh.pa.us, rjuju123@gmail.com, michael@paquier.xyz, andres@anarazel.de, peter.eisentraut@2ndquadrant.com, jcasanov@systemguards.com.ec, pgsql-hackers@lists.postgresql.org
Subject: Re: SQL-standard function body
In-Reply-To: <20210410200326.GD978274@rfd.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox