From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
cc: Andres Freund <andres@anarazel.de>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Oleg Bartunov <obartunov@postgrespro.ru>,
        Michael Paquier <michael@paquier.xyz>,
        Stas Kelvich <s.kelvich@postgrespro.ru>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Thomas Munro <thomas.munro@enterprisedb.com>,
        David Steele <david@pgmasters.net>,
        Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Pavel Stehule <pavel.stehule@gmail.com>
Subject: Re: jsonpath
In-reply-to: 
 <CAPpHfdtRC8CfnXA-a4f5vidVdMSveVMVa904qfO6tevqeZQDag@mail.gmail.com>
References: 
 <CAPpHfdv2bro1224314aRijKJu1bfwEimKr6hExoOaF4sqSDTQA@mail.gmail.com>
 <CAF4Au4zTZ18j_7Q4VeiJvJ3egJkEQtu7MfgU_ADp5pYVbdnkpA@mail.gmail.com>
 <264a6413-7175-9680-b976-d50392c001c0@postgrespro.ru>
 <CAPpHfdtxOuEu4t-uGwJF9qzusAmViBf_e3cLYUx1mEoqwWD21g@mail.gmail.com>
 <CAPpHfdu4nKqccH0tE84fTJqc7qV-9_w_uic1_zGTYY4FEbQUOw@mail.gmail.com>
 <CAPpHfduk=0DOKa40A+0Gi-eo03on_7DZgLZV9vNGdgfUMF_v2w@mail.gmail.com>
 <CAPpHfdv+YtPtmircv0kDNH8t9CJ2u8NVGT0JMOxxG2Tdi9BAYg@mail.gmail.com>
 <eebc218c-7aaa-c425-6ba0-78b28c751830@2ndquadrant.com>
 <9f5f1247-29f4-17cd-edd9-38e9bcd95b14@postgrespro.ru>
 <CAPpHfdsxacOREFDAhhZFwL=-x8Z49LCrEK8T9Zn=SJY-EJ+S_Q@mail.gmail.com>
 <20190129010332.i4t64evqc3bwtjzx@alap3.anarazel.de>
 <CAPpHfdtRC8CfnXA-a4f5vidVdMSveVMVa904qfO6tevqeZQDag@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <a.korotkov@postgrespro.ru>
	message dated "Tue, 29 Jan 2019 04:30:31 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2108.1548726783.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Jan 2019 20:53:03 -0500
Message-ID: <2109.1548726783@sss.pgh.pa.us>
Precedence: bulk

Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> +             if (jspThrowErrors(cxt) ||
> +                     ERRCODE_TO_CATEGORY(errcode) !=3D ERRCODE_DATA_EXC=
EPTION)
> +                     PG_RE_THROW();

> BTW, this code also looks... useless.  I can't see whole numeric.c
> throwing ERRCODE_DATA_EXCEPTION.   Nikita, what do we mean here?

I think what this code is claiming is that any errcode in the 22xxx
category is safe to trap.  Presumably what it's expecting to see is
ERRCODE_DIVISION_BY_ZERO (22012) or another error that numeric.c
could throw ... but 22xxx covers a heck of a lot of ground.

			regards, tom lane