Re: jsonpath

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: 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:06:39
Message-ID: CAA8=A796mY7kJdKARt7B+faW70-c8mRh+Ff_joBJ+NyCFLv3Gg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 2, 2018 at 8:27 AM, Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> 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.
>

I haven't seen a response to this email. Do we need one before
proceeding any further with jsonpath?

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

  • Re: jsonpath at 2018-03-01 21:57:37 from Alexander Korotkov

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-03-20 05:09:00 Re: jsonpath
Previous Message Ashutosh Bapat 2018-03-20 05:03:56 Re: [HACKERS] Partition-wise aggregation/grouping