Re: ON ERROR in json_query and the like

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Markus Winand <markus(dot)winand(at)winand(dot)at>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ON ERROR in json_query and the like
Date: 2024-06-19 13:32:57
Message-ID: CACJufxG-i=ea3OxteNajt0RaReW+jGf+nVYQabOnyMt89BAt2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 17, 2024 at 9:07 PM Markus Winand <markus(dot)winand(at)winand(dot)at> wrote:
>
>
> I think it affects the following feature IDs:
>
> - T821, Basic SQL/JSON query operators
> For JSON_VALUE, JSON_TABLE and JSON_EXISTS
> - T828, JSON_QUERY
>
> Also, how hard would it be to add the functions that accept
> character strings? Is there, besides the effort, any thing else
> against it? I’m asking because I believe once released it might
> never be changed — for backward compatibility.
>

we have ExecEvalCoerceViaIOSafe, so it's doable.
I tried, but other things break. so it's not super easy i think.

because of eval_const_expressions_mutator, postgres will constantly
evaluate simple const expressions to simplify some expressions.
`SELECT JSON_QUERY('a', '$');`
postgres will try to do the cast coercion from text 'a' to jsonb. but
it will fail, but it's hard to send the cast failed information to
later code,
in ExecInterpExpr. in ExecEvalCoerceViaIOSafe, if we cast coercion
failed, then this function value is zero, isnull is set to true.

`SELECT JSON_QUERY('a', '$');`
will be equivalent to
`SELECT JSON_QUERY(NULL, '$');`

so making one of the next 2 examples to return jsonb 1 would be hard
to implement.
SELECT JSON_QUERY('a', '$' default '1' on empty);
SELECT JSON_QUERY('a', '$' default '1' on error);

--------------------------------------------------------------------------
If the standard says the context_item can be text string (cannot cast
to json successfully). future version we make it happen,
then it should be fine?
because it's like the previous version we are not fully compliant with
standard, now the new version is in full compliance with standard.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2024-06-19 13:35:36 Re: Avoid orphaned objects dependencies, take 3
Previous Message Richard Guo 2024-06-19 13:30:39 Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan