| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: jsonpath |
| Date: | 2018-03-20 05:36:18 |
| Message-ID: | 19506.1521524178@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-03-20 05:56:08 | Re: Problem while setting the fpw with SIGHUP |
| Previous Message | Dilip Kumar | 2018-03-20 05:13:55 | Re: Problem while setting the fpw with SIGHUP |