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

Robert Haas <robertmhaas@gmail.com> writes:
> Probably the thorniest problem is the backend's widespread dependence
> on ereport() and elog(). Now, it would not be enormously difficult to
> code up something that will sigsetjmp() and siglongjmp() in front-end
> code just as we do in backend code, but I think it would be largely
> missing the point.

Agreed that we don't want to introduce anything like transaction
abort recovery in our frontend tools.

> That being said, not all uses of ereport() and elog() are created
> equal. Sometimes, they are just used to report warnings, which
> typically don't contain much more than a primary message, and
> sometimes they are used to report can't-happen conditions, which ERROR
> in backend code and could probably just print a message and exit() in
> frontend code. Providing a general way to do this kind of thing seems
> a lot easier than solving the whole problem,

I think the $64 question is whether handling those two cases is sufficient
for *all* elog/ereport usages in the code we'd like to move to src/common.
If it is, great; but if it isn't, we still have a problem to solve, and
it's not clear that solving that problem won't yield a better answer for
these cases too.

> Taking a page from my Perl programming background, I propose to
> call these pg_carp() and pg_croak(), although I'm not in love with
> those names so let the bikeshedding commence.

Yeah, I'm not in love with those names either, partly because I think
they carry some baggage about when to use them and what the reports
are likely to look like.  But sans caffeine, I don't have a better idea
either.

> Something like:
> #ifdef FRONTEND
> #define pg_croak(...) do { pg_log_fatal(__VA_ARGS__); exit(1) } while (0)
> #define pg_carp(...) pg_log_warning(__VA_ARGS__);
> #else
> #define pg_croak(...) elog(ERROR, __VA_ARGS__)
> #define pg_carp(...) elog(WARNING, __VA_ARGS__)
> #endif

Hm, the thing that jumps out at me about those is the lack of attention
to translatability.  Sure, for really "can't happen" cases we probably
just want to use bare elog with a non-translated message.  But warnings
are user-facing, and there will be an enormous temptation to use the
croak mechanism for user-facing errors too, and those should be
translated.  There's also a problem that there's noplace to add an
ERRCODE; that's flat out not acceptable for backend code that's
reporting anything but absolutely-cannot-happen cases.

> It is of course somewhat questionable to consider a "croak" as
> effectively *fatal* on the frontend side but only ERROR rather than
> FATAL on the backend side, but for the kinds of things I'm looking at
> it seems like the most useful definition.

Agreed there.

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.

            regards, tom lane