Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>> That seems like a quite limited list of functions. What about
>> reworking them providing a way of calling them without risk of
>> exception?
> I haven't seen a response to this email. Do we need one before
> proceeding any further with jsonpath?
I've not been following this thread in detail, but IMO any code anywhere
that thinks that no error can be thrown out of non-straight-line code is
broken beyond redemption. What, for example, happens if we get ENOMEM
within one of the elog.c functions?
I did look through 0007-jsonpath-arithmetic-error-handling-v12.patch,
and I can't believe that's seriously proposed for commit. It's making
some pretty fragile changes in error handling, and so far as I can
find there is not even one line of commentary as to what the new
design rules are supposed to be. Even if it's completely bug-free
today (which I would bet against), how could we keep it so?
regards, tom lane
