Re: ON ERROR in json_query and the like
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Chapman Flack <jcflack@acm.org>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
Markus Winand <markus.winand@winand.at>, pgsql-hackers@postgresql.org
Date: 2024-06-20T07:55:19Z
Lists: pgsql-hackers
Hi,
On Mon, Jun 17, 2024 at 9:47 PM Chapman Flack <jcflack@acm.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
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