Re: pg_croak, or something like it?

On Mon, Jan 27, 2020 at 11:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

It's hard to refute a statement this general; it can only devolve into
an argument about what we will want to do in the future. And, if I may
be permitted to appeal to a highier authority on that topic, I think
this quote is highly relevant: "Difficult to see. Always in motion is
the future."

What I was hoping to do in this thread was to focus on the problem of
which I have several instances immediately at hand, which is handling
can't-happen conditions, rather than blowing open the issue in its
full generality. I think there is a meaningful amount of code in the
backend where that is, or can be made to be, the only issue that needs
to be solved, and I therefore think that it is a reasonable special
case to tackle first. Of course, I can't force you to have that
conversation, but I don't think refusing to have it is going to make
the problem go away. Realistically, people aren't going to stop moving
code to src/common; what they're going to do is put special-case hacks
in each file, like we already have in a couple of places, instead of
using some more general solution upon which we might try to agree.

In other words, somebody who comes across a chunk of code that uses
ereport() extensively might conceivably give up on moving it to
src/common, but somebody who finds one elog(ERROR, "oops this is
broken") is not going to for that reason give up. They are going to do
something to get around it. Better for them all to do the same thing,
and something that's had some general thought given to it, than for
each person who runs into such a problem to hand-roll their own way of
handling it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company