Re: Better error messages for %TYPE and %ROWTYPE in plpgsql - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Better error messages for %TYPE and %ROWTYPE in plpgsql
Date
Msg-id CAKFQuwZaQOL2wMT=gGvtWWPcF1Gd9mb6vrxzicUtc=xdFEDEYw@mail.gmail.com
Whole thread Raw
In response to Re: Better error messages for %TYPE and %ROWTYPE in plpgsql  (Andy Fan <zhihuifan1213@163.com>)
List pgsql-hackers
On Mon, Feb 26, 2024 at 6:54 PM Andy Fan <zhihuifan1213@163.com> wrote:

"David G. Johnston" <david.g.johnston@gmail.com> writes:

> On Mon, Feb 26, 2024 at 5:46 PM Andy Fan <zhihuifan1213@163.com> wrote:
>
>  > Per recent discussion[1], plpgsql returns fairly unhelpful "syntax
>  > error" messages when a %TYPE or %ROWTYPE construct references a
>  > nonexistent object.  Here's a quick little finger exercise to try
>  > to improve that.
>
>  Looks this modify the error message, I want to know how ould we treat
>  error-message-compatible issue during minor / major upgrade.
>
> There is no bug here so no back-patch; and we are not yet past feature freeze for v17.

Acutally I didn't asked about back-patch.

What else should I be understanding when you write the words "minor upgrade"?
 
So if the error message is changed, the above code may be broken.


A fair point to bring up, and is change-specific.  User-facing error messages should be informative and where they are not changing them is reasonable.  Runtime errors probably need more restraint since they are more likely to be in a production monitoring alerting system but anything that is reporting what amounts to a syntax error should be reasonable to change and not expect people to be writing production code looking for them.  This seems to fall firmly into the "badly written code"/syntax category.

David J.

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring
Next
From: Michael Paquier
Date:
Subject: Re: Printing backtrace of postgres processes