Re: SQL-standard function body - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL-standard function body
Date
Msg-id 2298215.1618066335@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL-standard function body  (Noah Misch <noah@leadboat.com>)
Responses Re: SQL-standard function body
List 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



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: Truncate in synchronous logical replication failed
Next
From: Tom Lane
Date:
Subject: Re: check_function_bodies: At least the description seems wrong, since we have prodedures