On Tue, Mar 20, 2018 at 3:36 PM, Andrew Dunstan <andrew.duns...@2ndquadrant.com> wrote: > On Fri, Mar 2, 2018 at 8:27 AM, Alexander Korotkov > <a.korot...@postgrespro.ru> wrote: >> On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov <n.glu...@postgrespro.ru> >> wrote: >>> >>> On 28.02.2018 06:55, Robert Haas wrote: >>> >>>> On Mon, Feb 26, 2018 at 10:34 AM, Nikita Glukhov >>>> <n.glu...@postgrespro.ru> wrote: >>>>> >>>>> Attached 10th version of the jsonpath patches. >>>>> >>>>> 1. Fixed error handling in arithmetic operators. >>>>> >>>>> Now run-time errors in arithmetic operators are catched (added >>>>> PG_TRY/PG_CATCH around operator's functions calls) and converted >>>>> into >>>>> Unknown values in predicates as it is required by the standard: >>>> >>>> I think we really need to rename PG_TRY and PG_CATCH or rethink this >>>> whole interface so that people stop thinking they can use it to >>>> prevent errors from being thrown. >>> >>> >>> I understand that it is unsafe to call arbitrary function inside PG_TRY >>> without >>> rethrowing of caught errors in PG_CATCH, but in jsonpath only the >>> following >>> numeric and datetime functions with known behavior are called inside >>> PG_TRY >>> and only errors of category ERRCODE_DATA_EXCEPTION are caught: >>> >>> numeric_add() >>> numeric_mul() >>> numeric_div() >>> numeric_mod() >>> numeric_float8() >>> float8in() >>> float8_numeric() >>> to_datetime() >> >> >> That seems like a quite limited list of functions. What about reworking >> them >> providing a way of calling them without risk of exception? For example, we >> can >> have numeric_add_internal() function which fill given data structure with >> error information instead of throwing the error. numeric_add() would be a >> wrapper over numeric_add_internal(), which throws an error if corresponding >> data structure is filled. In jsonpath we can call numeric_add_internal() >> and >> interpret errors in another way. That seems to be better than use of PG_TRY >> and PG_CATCH. >> > > > I haven't seen a response to this email. Do we need one before > proceeding any further with jsonpath? >
Apologies. I see the reply now. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
