Re: feature request ctid cast / sql exception - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: feature request ctid cast / sql exception
Date
Msg-id CAKFQuwY6K4ZM3dCMqqcM5pgQ8=uH3+f4BFtzXBRF-7hji0Hf0A@mail.gmail.com
Whole thread Raw
In response to Re: feature request ctid cast / sql exception  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Saturday, April 17, 2021, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml. <v.houba@gmail.com>
> wrote:
>> Another nice feature would be a function that can be called from a sql
>> statement and would throw an exception when executed.

> An assertion-related extension in core would be welcomed.

This has been suggested before, but as soon as you start looking
at the details you find that it's really hard to get a one-size-fits-all
definition that's any simpler than the existing plpgsql RAISE
functionality.

Even just getting raise functionality as a standard functional api would be a win.  I don’t imagine enough users would care enough to write their own routines if one already existed, even if they would argue details about how to create it in the first place.  For the expected use case of basically developer-oriented error messages there is generally a acceptance of taking the sufficient solution.

David J. 

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: feature request ctid cast / sql exception
Next
From: Tom Lane
Date:
Subject: Re: Replication slot stats misgivings