From: Nikita Glukhov <n.gluhov@postgrespro.ru>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Oleg Bartunov <obartunov@gmail.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: jsonpath
Date: Wed, 7 Mar 2018 17:33:10 +0300
Message-ID: <c19ee9e4-e832-efc3-d6cf-3cacc6462315@postgrespro.ru> (raw)
In-Reply-To: <CAPpHfduYzfOrtS0i2XuKpBRJY5ZhhdV7yw89U3HaXEjymfBhTQ@mail.gmail.com>
References: <fcc6fc6a-b497-f39a-923d-aa34d0c588e8@2ndQuadrant.com>
<9f845926-0d7d-7c4d-75e3-b1e921a1677a@2ndQuadrant.com>
<CAFj8pRBCvhgLCROfSCPGmwWZpSY+dKQN4O9xRe+1-wjBiXiHkA@mail.gmail.com>
<bad98003-31ba-523e-d76c-3679efb2e732@2ndQuadrant.com>
<CAFj8pRDWSCWd1JxA8srwbfL5cPgz2b5minq2UsM=cxgsFF-orw@mail.gmail.com>
<48f13b75-0be7-c356-ff26-1db743add56e@postgrespro.ru>
<7b4b8973-43f5-71c5-bf86-51cb5798dd88@2ndQuadrant.com>
<f0b44fe7-d47a-eff2-592c-d9dbe4a63f75@2ndQuadrant.com>
<5290ddd1-f23e-a53a-cae0-830dbde0a5fe@2ndQuadrant.com>
<604ffe9c-b42e-7c42-e16b-aa44c3a12c3c@postgrespro.ru>
<927f72f0-6832-a4ca-5676-b0ab5a2895d4@postgrespro.ru>
<CAF4Au4wxHuEeZrMxxKXUYcs1kDws-f0oW0-sEyun388-U-NOxw@mail.gmail.com>
<9a1ac993-7608-797c-2095-c735605da82f@postgrespro.ru>
<CA+TgmoYXtoPPaV-OEUfqujCcfKp+ZT=KOuPHkhRoQL_iYzQ8yQ@mail.gmail.com>
<94ace92c-714c-903c-fab2-31fb838204ad@postgrespro.ru>
<CAPpHfduYzfOrtS0i2XuKpBRJY5ZhhdV7yw89U3HaXEjymfBhTQ@mail.gmail.com>
On 02.03.2018 00:57, Alexander Korotkov wrote:
> On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov
> <n.gluhov@postgrespro.ru <mailto: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 <mailto: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.
Attached 12th version of jsonpath patches.
I added the 7th patch where the following functions were extracted for
safe error handling in jsonpath:
numeric_add_internal()
numeric_sub_internal()
numeric_mul_internal()
numeric_div_internal()
numeric_mod_internal()
float8_numeric_internal()
numeric_float8_internal()
float8in_internal()
Errors are passed to caller with new ereport_safe() macro when
ErrorData **edata is not NULL:
+#define ereport_safe(edata, elevel, rest) \
+ do { \
+ if (edata) { \
+ errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO, TEXTDOMAIN); \
+ (rest); \
+ *(edata) = CopyErrorData(); \
+ FlushErrorState(); \
+ } else { \
+ ereport(elevel, rest); \
+ } \
+ } while (0)
But to_datetime() is still called in jsonpath inside PG_TRY/PG_CATCH block
because it needs too deep error propagation.
--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachments:
[application/gzip] sqljson_jsonpath_v12.tar.gz (85.9K, ../c19ee9e4-e832-efc3-d6cf-3cacc6462315@postgrespro.ru/3-sqljson_jsonpath_v12.tar.gz)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: n.gluhov@postgrespro.ru, a.korotkov@postgrespro.ru, robertmhaas@gmail.com, obartunov@gmail.com, andrew.dunstan@2ndquadrant.com, pavel.stehule@gmail.com
Subject: Re: jsonpath
In-Reply-To: <c19ee9e4-e832-efc3-d6cf-3cacc6462315@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox