Re: jsonpath

Wed, 07 Mar 2018 06:34:10 -0800 

On 02.03.2018 00:57, Alexander Korotkov wrote:
On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov <[email protected] <mailto:[email protected]>> wrote: 

    On 28.02.2018 06:55, Robert Haas wrote:

        On Mon, Feb 26, 2018 at 10:34 AM, Nikita Glukhov
        <[email protected] <mailto:[email protected]>> 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





Attachment:
sqljson_jsonpath_v12.tar.gz

Description: application/gzip






















					Reply via email to