Re: jsonpath

On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
wrote:

> On 28.02.2018 06:55, Robert Haas wrote:
>
> On Mon, Feb 26, 2018 at 10:34 AM, Nikita Glukhov
>> <n(dot)gluhov(at)postgrespro(dot)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.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company