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: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-01-16T19:11:14Z
Lists: pgsql-hackers 
On 1/15/20 7:39 PM, Robert Haas wrote:
 > On Wed, Jan 15, 2020 at 6:40 PM Andres Freund <andres@anarazel.de> wrote:
 >> It's not obvious why the better approach here wouldn't be to just have a
 >> very simple ereport replacement, that needs to be explicitly included
 >> from frontend code. It'd not be meaningfully harder, imo, and it'd
 >> require fewer adaptions, and it'd look more familiar.
 >
 > I agree that it's far from obvious that the hacks in the patch are
 > best; to the contrary, they are hacks. That said, I feel that the
 > semantics of throwing an error are not very well-defined in a
 > front-end environment. I mean, in a backend context, throwing an error
 > is going to abort the current transaction, with all that this implies.
 > If the frontend equivalent is to do nothing and hope for the best, I
 > doubt it will survive anything more than the simplest use cases. This
 > is one of the reasons I've been very reluctant to go do down this
 > whole path in the first place.

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.

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.