Re: pg_croak, or something like it?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_croak, or something like it?
Date: 2020-01-27 16:07:53
Message-ID: 6932.1580141273@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 27, 2020 at 10:50 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-01-27 16:12:26 Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Previous Message Robert Haas 2020-01-27 15:56:02 Re: pg_croak, or something like it?