> On 21.06.2024, at 06:46, David G. Johnston <david.g.johns...@gmail.com> wrote:
>>
>> On Thursday, June 20, 2024, Pavel Stehule <pavel.steh...@gmail.com> wrote:
>>
>>
>> pá 21. 6. 2024 v 6:01 odesílatel Amit Langote <amitlangot...@gmail.com>
>> napsal:
>> On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston
>> <david.g.johns...@gmail.com> 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
