Re: pg_croak, or something like it? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_croak, or something like it?
Date
Msg-id 6932.1580141273@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_croak, or something like it?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_croak, or something like it?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 27, 2020 at 10:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What it sounds to me like you want to do is implement (some equivalent of)
>> elog() but not ereport() for this environment.  I'm going to resist that
>> pretty strongly, because I think it will lead directly to abuse of elog()
>> for user-facing errors, with a consequent degradation of the user
>> experience when that code executes on backend side.  I do not believe
>> that there are no user-facing error cases in the JSON parser, for
>> example; much less that we'll never introduce any in future.

> You clearly haven't read the thread on this topic, or at least not
> very carefully.

I have not, but I'm still going to stand by that point.  It is not
credible that the code we will want to share between frontend and
backend will never contain any user-facing error reports.  Designing
a reporting mechanism that assumes that is just going to lead to
degraded reporting of things that are indeed user-facing.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_croak, or something like it?
Next
From: Andres Freund
Date:
Subject: Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()