David Steele <david@pgmasters.net> writes:
> On 1/15/20 7:39 PM, Robert Haas wrote:
>>> 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.
If that's the expectation, we might as well replace backend ereport(ERROR)
with something that just prints a message and does exit(1).
The question comes down to whether there are use-cases where a frontend
application would really want to recover and continue processing after
a JSON syntax problem. I'm not seeing that that's a near-term
requirement, so maybe we could leave it for somebody to solve when
and if they want to do it.
regards, tom lane
