On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov <n.glu...@postgrespro.ru> wrote:
> On 28.02.2018 06:55, Robert Haas wrote: > > On Mon, Feb 26, 2018 at 10:34 AM, Nikita Glukhov >> <n.glu...@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. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
