Re: ON ERROR in json_query and the like
От | Amit Langote |
---|---|
Тема | Re: ON ERROR in json_query and the like |
Дата | |
Msg-id | CA+HiwqH1wXJnASrhXcijzqMx6sKznXbE093E6MUBPQGDR2ifwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ON ERROR in json_query and the like (Markus Winand <markus.winand@winand.at>) |
Ответы |
Re: ON ERROR in json_query and the like
|
Список | 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 по дате отправления: