Re: pg_croak, or something like it?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 27, 2020 at 10:08 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What I keep thinking is that we should stick with ereport() as the
>> reporting notation, and invent a frontend-side implementation of it
>> that covers the cases you mention (ie WARNING and ERROR ... and maybe
>> DEBUG?), ignoring any components of the ereport that aren't helpful for
>> the purpose. That'd eliminate the temptation to shave the quality of
>> the backend-side error reports, and we still end up with about the same
>> basic functionality on frontend side.

> Well, the cases that I'm concerned about use elog(), not ereport(), so
> I don't think this would help me very much.

So? elog() is just a specific degenerate case of ereport(). If we have
a way to implement ereport() on frontend side then we can surely do
elog() too.

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.

> That's not a step forward in my book, especially because it'll be
> *necessary* for code in src/common and optional in other places. Also,
> using ereport() -- or elog() -- in frontend code seems like a large
> step down the slippery slope of leading people to believe that error
> recovery in the frontend can, does, or should work like error recovery
> in the backend, and I think if we do even the slightest thing to feed
> that impression we will regret it bitterly.

I'm not exactly buying that. For subsystems like the JSON parser,
at least, either elog or ereport with ERROR just means "I'm throwing
up my hands, what happens next does not concern me". I don't see
any problem with interpreting that as leading to exit(1) on frontend
side. I'm also not seeing why using some other, randomly different
notation for what are fundamentally going to be the same semantics
would really improve the situation.

regards, tom lane