Re: feature request ctid cast / sql exception

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vladimír Houba ml(dot) <v(dot)houba(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: feature request ctid cast / sql exception
Date: 2021-04-17 21:48:41
Message-ID: CAKFQuwY6K4ZM3dCMqqcM5pgQ8=uH3+f4BFtzXBRF-7hji0Hf0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday, April 17, 2021, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml. <v(dot)houba(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-04-17 22:15:36 Re: Replication slot stats misgivings
Previous Message David G. Johnston 2021-04-17 21:05:30 Re: feature request ctid cast / sql exception