On Tue, Mar 20, 2018 at 3:36 PM, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:
> On Fri, Mar 2, 2018 at 8:27 AM, Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
>> On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov <n.gluhov@postgrespro.ru>
>> wrote:
>>>
>>> On 28.02.2018 06:55, Robert Haas wrote:
>>>
>>>> On Mon, Feb 26, 2018 at 10:34 AM, Nikita Glukhov
>>>> <n.gluhov@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
