public inbox for [email protected]
help / color / mirror / Atom feedFrom: Markus Winand <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: Amit Langote <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: ON ERROR in json_query and the like
Date: Fri, 21 Jun 2024 07:28:22 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwb7C1+6zCB7TJwFMxTs=m7N=Q6S0ONtpZB-2vMFBsuaUw@mail.gmail.com>
References: <[email protected]>
<CAFj8pRBfkdqMGG+WVwT6tEaNgw1u301z=2mhMp8e77M9H2dmEQ@mail.gmail.com>
<CA+HiwqGuqLfAEP-FwW3QHByfQOoUpyj6YZG6R6bScpQswvNYDA@mail.gmail.com>
<[email protected]>
<CA+HiwqF2Z6FATWQV6bG9NeKYf=++fOgmdbYc9gWSNJ81jfqCuA@mail.gmail.com>
<CAKFQuwa4Ei=A-XbGXQ6Q6AxhDSZ4iKL376ek0Kd51yxm1jDtMQ@mail.gmail.com>
<CA+HiwqG-Yq3EU=PXYbQXaqg-0KoHNtuRPh2oaUj+5xE_P2Jp_w@mail.gmail.com>
<CAKFQuwakKgGi_jsmf7fEryx_NV-wiEVdAbUOB8GvD6kAuz+Fyg@mail.gmail.com>
<CA+HiwqFYNWSZ7Ncj6KVfj7eVpTUs9rDrort9UKM6FKDuy9k4Jw@mail.gmail.com>
<CAFj8pRC=dsGe1fcidhhdRTy16=SQeX5XAQ0YWtsX0zieVcX9=A@mail.gmail.com>
<CAKFQuwb7C1+6zCB7TJwFMxTs=m7N=Q6S0ONtpZB-2vMFBsuaUw@mail.gmail.com>
> On 21.06.2024, at 06:46, David G. Johnston <[email protected]> wrote:
>>
>> On Thursday, June 20, 2024, Pavel Stehule <[email protected]> wrote:
>>
>>
>> pá 21. 6. 2024 v 6:01 odesílatel Amit Langote <[email protected]> napsal:
>> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
>> <[email protected]> wrote:
>>
>> > > By the standard, it is implementation-defined whether JSON parsing errors
>> > > should be caught by ON ERROR clause.
>> >
>> > Absent someone contradicting that claim I retract my position here and am fine with failing if these "functions" are supplied with something that cannot be cast to json. I'd document them like functions that accept json with the implications that any casting to json happens before the function is called and thus its arguments do not apply to that step.
>>
>> Thanks for that clarification.
>>
>> So, there are the following options:
>>
>> 1. Disallow anything but jsonb for context_item (the patch I posted yesterday)
>>
>> 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.
>>
>> 3. Go ahead and fix implicit casts to jsonb so that any parsing errors
>> respect ON ERROR (no patch written yet).
>>
>> David's vote seems to be 2, which is my inclination too. Markus' vote
>> seems to be either 1 or 3. Anyone else?
With a very strong preference of 3.
>>
>> @3 can be possibly messy (although be near Oracle or standard). I don't think it is safe - one example '{a:10}' is valid for Oracle, but not for Postgres, and using @3 impacts different results (better to raise an exception).
The question of what is valid JSON is a different question, I guess. My original report is about something that is invalid everywhere. Having that in line would be a start. Also I believe Oracle’s habit to accept unquoted object keys is not covered by the standard (unless defined as a JSON format and also explicitly using the corresponding FORMAT clause).
>> The effect of @1 and @2 is similar - @1 is better so the user needs to explicitly cast, so maybe it is cleaner, so the cast should not be handled, @2 is more user friendly, because it accepts unknown string literal. From a developer perspective I prefer @1, from a user perspective I prefer @2. Maybe @2 is a good compromise.
>
> 2 also has the benefit of being standard conforming while 1 does not.
Why do you think so? Do you have any references or is this just based on previous statements in this discussion?
-markus
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: ON ERROR in json_query and the like
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox