Horton

Re: making the backend's json parser work in frontend code

David Steele <david@pgmasters.net>

View thread View on postgr.es
From: David Steele <david@pgmasters.net>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-01-16T20:10:53Z
Lists: pgsql-hackers 
On 1/16/20 12:26 PM, Andres Freund wrote:
> Hi,
> 
> On 2020-01-16 14:20:28 -0500, Tom Lane wrote:
>> David Steele <david@pgmasters.net> writes:
>>> The way we handle this in pgBackRest is to put a TRY ... CATCH block in
>>> main() to log and exit on any uncaught THROW.  That seems like a
>>> reasonable way to start here.  Without memory contexts that almost
>>> certainly will mean memory leaks but I'm not sure how much that matters
>>> if the action is to exit immediately.
>>
>> If that's the expectation, we might as well replace backend ereport(ERROR)
>> with something that just prints a message and does exit(1).
> 
> Well, the process might still want to do some cleanup of half-finished
> work. You'd not need to be resistant against memory leaks to do so, if
> followed by an exit. Obviously you can also do all the necessarily
> cleanup from within the ereport(ERROR) itself, but that doesn't seem
> appealing to me (not composable, harder to reuse for other programs,
> etc).

In pgBackRest we have a default handler that just logs the message to 
stderr and exits (though we consider it a coding error if it gets 
called).  Seems like we could do the same here.  Default message and 
exit if no handler, but optionally allow a handler (which could RETHROW 
to get to the default handler afterwards).

It seems like we've been wanting a front end version of ereport() for a 
while so I'll take a look at that and see what it involves.

Regards,
-- 
-David
david@pgmasters.net

Commits

  1. Add jsonapi.c to Mkvcbuild.pm's @pgcommonallfiles.

  2. Move jsonapi.c and jsonapi.h to src/common.

  3. Move some code from jsonapi.c to jsonfuncs.c.

  4. Adjust pg_parse_json() so that it does not directly ereport().

  5. Remove jsonapi.c's lex_accept().

  6. Split JSON lexer/parser from 'json' data type support.

  7. Rationalize code placement between wchar.c, encnames.c, and mbutils.c.

  8. Move wchar.c and encnames.c to src/common/.

  9. Update header comments for wchar.c and encnames.c.

  10. Make StringInfo available to frontend code.

  11. Use SASLprep to normalize passwords for SCRAM authentication.