Re: ON ERROR in json_query and the like

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: ON ERROR in json_query and the like
Дата
Msg-id CA+HiwqFhQsjehP8hu4C2Xk2z=T4BBXf9NvzwgaDCubVp-T=bsw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ON ERROR in json_query and the like  (Amit Langote <amitlangote09@gmail.com>)
Список 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
andalso that 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.
>
> 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: Virtual generated columns
Следующее
От:
Дата:
Сообщение: Re: Doc: fix track_io_timing description to mention pg_stat_io