Re: making the backend's json parser work in frontend code
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Steele <david@pgmasters.net>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-01-16T19:26:24Z
Lists: pgsql-hackers
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). Greetings, Andres Freund
Commits
-
Add jsonapi.c to Mkvcbuild.pm's @pgcommonallfiles.
- 006b9dcad419 13.0 landed
-
Move jsonapi.c and jsonapi.h to src/common.
- beb4699091e9 13.0 landed
-
Move some code from jsonapi.c to jsonfuncs.c.
- 73ce2a03f30b 13.0 landed
-
Adjust pg_parse_json() so that it does not directly ereport().
- 1f3a021730be 13.0 landed
-
Remove jsonapi.c's lex_accept().
- 530609aa4263 13.0 landed
-
Split JSON lexer/parser from 'json' data type support.
- 11b5e3e35d39 13.0 landed
-
Rationalize code placement between wchar.c, encnames.c, and mbutils.c.
- 5afaa2e42655 13.0 landed
-
Move wchar.c and encnames.c to src/common/.
- e6afa8918c46 13.0 landed
-
Update header comments for wchar.c and encnames.c.
- 3d4cb5d6c180 13.0 landed
-
Make StringInfo available to frontend code.
- 26aaf97b683d 13.0 cited
-
Use SASLprep to normalize passwords for SCRAM authentication.
- 60f11b87a234 10.0 cited