Re: ON ERROR in json_query and the like - Mailing list pgsql-hackers

From Amit Langote
Subject Re: ON ERROR in json_query and the like
Date
Msg-id CA+HiwqH1wXJnASrhXcijzqMx6sKznXbE093E6MUBPQGDR2ifwQ@mail.gmail.com
Whole thread Raw
In response to Re: ON ERROR in json_query and the like  (Markus Winand <markus.winand@winand.at>)
Responses Re: ON ERROR in json_query and the like
List pgsql-hackers
Hi,

Thanks all for chiming in.

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
alsothat it is IMHO what users would expect. However, as 2 is also conforming (how could I miss that?), proper
documentationis 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.


--
Thanks, Amit Langote



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: SQL/JSON query functions context_item doc entry and type requirement
Next
From: Alexander Lakhin
Date:
Subject: recoveryCheck/008_fsm_truncation is failing on dodo in v14- (due to slow fsync?)