Re: ON ERROR in json_query and the like

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Chapman Flack <jcflack(at)acm(dot)org>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Markus Winand <markus(dot)winand(at)winand(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ON ERROR in json_query and the like
Date: 2024-06-20 07:55:19
Message-ID: CA+HiwqFRNCu_N+hTvuS5nrq5KA8WUu7tOtG0ESaNSqaBba7wQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Jun 17, 2024 at 9:47 PM Chapman Flack <jcflack(at)acm(dot)org> wrote:
> On 06/17/24 02:20, Amit Langote wrote:
> >>> Apparently, the functions expect JSONB so that a cast is implied
> >>> when providing TEXT. However, the errors during that cast are
> >>> not subject to the ON ERROR clause.
> >>>
> >>> 17beta1=# SELECT JSON_QUERY('invalid', '$' NULL ON ERROR);
> >>> ERROR: invalid input syntax for type json
> >>> DETAIL: Token "invalid" is invalid.
> >>> CONTEXT: JSON data, line 1: invalid
> >>>
> >>> Oracle DB and Db2 (LUW) both return NULL in that case.
>
> I wonder, could prosupport rewriting be used to detect that the first
> argument is supplied by a cast, and rewrite the expression to apply the
> cast 'softly'? Or would that behavior be too magical?

I don't think prosupport rewriting can be used, because JSON_QUERY().

We could possibly use "runtime coercion" for context_item so that the
coercion errors can be "caught", which is how we coerce the jsonpath
result to the RETURNING type.

For now, I'm inclined to simply document the limitation that errors
when coercing string arguments to json are always thrown.

--
Thanks, Amit Langote

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2024-06-20 07:58:28 Re: suspicious valgrind reports about radixtree/tidstore on arm64
Previous Message Peter Eisentraut 2024-06-20 07:29:45 Re: Remove distprep