From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Markus Winand <markus(dot)winand(at)winand(dot)at>, 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-20 16:11:16 |
Message-ID: | CAKFQuwa4Ei=A-XbGXQ6Q6AxhDSZ4iKL376ek0Kd51yxm1jDtMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 20, 2024 at 2:19 AM Amit Langote <amitlangote09(at)gmail(dot)com>
wrote:
> Hi,
>
> On Mon, Jun 17, 2024 at 10:07 PM Markus Winand <markus(dot)winand(at)winand(dot)at>
> wrote:
> > > On 17.06.2024, at 08:20, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > > Agree that the documentation needs to be clear about this. I'll update
> > > my patch at [1] to add a note next to table 9.16.3. SQL/JSON Query
> > > Functions.
> >
> > Considering another branch of this thread [1] I think the
> > "Supported Features” appendix of the docs should mention that as well.
> >
> > The way I see it is that the standards defines two overloaded
> > JSON_QUERY functions, of which PostgreSQL will support only one.
> > In case of valid JSON, the implied CAST makes it look as though
> > the second variant of these function was supported as well but that
> > illusion totally falls apart once the JSON is not valid anymore.
> >
> > 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.
>
> Hmm, I'm starting to think that adding the implied cast to json wasn't
> such a great idea after all, because it might mislead the users to
> think that JSON parsing is transparent (respects ON ERROR), which is
> what you are saying, IIUC.
>
>
Actually, the implied cast is exactly the correct thing to do here - the
issue is that we aren't using the newly added soft errors infrastructure
[1] to catch the result of that cast and instead produce whatever output on
error tells us to produce. This seems to be in the realm of doability so
we should try in the interest of being standard conforming. I'd even argue
to make this an open item unless and until the attempt is agreed upon to
have failed (or it succeeds of course).
David J.
[1] d9f7f5d32f201bec61fef8104aafcb77cecb4dcb
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2024-06-20 17:00:41 | Re: Extension security improvement: Add support for extensions with an owned schema |
Previous Message | jian he | 2024-06-20 16:01:11 | Re: SQL/JSON query functions context_item doc entry and type requirement |