Re: ON ERROR in json_query and the like
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Markus Winand <markus.winand@winand.at>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
Pavel Stehule <pavel.stehule@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Peter Eisentraut <peter@eisentraut.org>
Date: 2024-06-28T00:49:45Z
Lists: pgsql-hackers
On Wed, Jun 26, 2024 at 9:10 PM Amit Langote <amitlangote09@gmail.com> wrote: > On Sat, Jun 22, 2024 at 5:43 PM Amit Langote <amitlangote09@gmail.com> wrote: > > On Fri, Jun 21, 2024 at 8:00 PM Markus Winand <markus.winand@winand.at> wrote: > > > So updating the three options: > > > > 1. Disallow anything but jsonb for context_item (the patch I posted yesterday) > > > > > > * Non-conforming > > > * patch available > > > > > > > 2. Continue allowing context_item to be non-json character or utf-8 > > > > encoded bytea strings, but document that any parsing errors do not > > > > respect the ON ERROR clause. > > > > > > * Conforming by choosing IA050 to implement GR4: raise errors independent of the ON ERROR clause. > > > * currently committed. > > > > > > > 3. Go ahead and fix implicit casts to jsonb so that any parsing errors > > > > respect ON ERROR (no patch written yet). > > > > > > * Conforming by choosing IA050 not to implement GR4: Parsing happens later, considering the ON ERROR clause. > > > * no patch available, not trivial > > > > > > I guess I’m the only one in favour of 3 ;) My remaining arguments are that Oracle and Db2 (LUW) do it that way and also that it is IMHO what users would expect. However, as 2 is also conforming (how could I miss that?), proper documentation is a very tempting option. > > > > So, we should go with 2 for v17, because while 3 may be very > > appealing, there's a risk that it might not get done in the time > > remaining for v17. > > > > I'll post the documentation patch on Monday. > > Here's that patch, which adds this note after table 9.16.3. SQL/JSON > Query Functions: > > + <note> > + <para> > + The <replaceable>context_item</replaceable> expression is converted to > + <type>jsonb</type> by an implicit cast if the expression is not already of > + type <type>jsonb</type>. Note, however, that any parsing errors that occur > + during that conversion are thrown unconditionally, that is, are not > + handled according to the (specified or implicit) <literal>ON > ERROR</literal> > + clause. > + </para> > + </note> I have pushed this. -- Thanks, Amit Langote
Commits
-
SQL/JSON: Document behavior when input document is not jsonb
- 473a352fb393 17.0 landed
-
SQL/JSON: Correctly enforce the default ON EMPTY behavior
- 03ec20316411 17.0 landed
-
Create infrastructure for "soft" error reporting.
- d9f7f5d32f20 16.0 cited