(This is split off from my work on OAUTHBEARER [1].)
The jsonapi in src/common can't currently be compiled into libpq. The
first patch here removes the dependency on pg_log_fatal(), which is not
available to the sharedlib. The second patch makes sure that all of the
return values from json_errdetail() can be pfree'd, to avoid long-
running leaks.
In the original thread, Michael Paquier commented:
> +# define check_stack_depth()
> +# ifdef JSONAPI_NO_LOG
> +# define json_log_and_abort(...) \
> + do { fprintf(stderr, __VA_ARGS__); exit(1); } while(0)
> +# else
> In patch 0002, this is the wrong approach. libpq will not be able to
> feed on such reports, and you cannot use any of the APIs from the
> palloc() family either as these just fail on OOM. libpq should be
> able to know about the error, and would fill in the error back to the
> application. This abstraction is not necessary on HEAD as
> pg_verifybackup is fine with this level of reporting. My rough guess
> is that we will need to split the existing jsonapi.c into two files,
> one that can be used in shared libraries and a second that handles the
> errors.
Hmm. I'm honestly hesitant to start splitting files apart, mostly
because json_log_and_abort() is only called from two places, and both
those places are triggered by programmer error as opposed to user
error.
Would it make more sense to switch to an fprintf-and-abort case, to
match the approach taken by PGTHREAD_ERROR and the out-of-memory
conditions in fe-print.c? Or is there already precedent for handling
can't-happen code paths with in-band errors, through the PGconn?
--Jacob
[1] https://www.postgresql.org/message-id/d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel@vmware.com