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.
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 |