On Fri, Jun 21, 2024 at 10:01 AM David G. Johnston <david.g.johnston@gmail.com> wrote: > On Thu, Jun 20, 2024 at 5:22 PM Amit Langote <amitlangote09@gmail.com> wrote: >> >> >> Soft error handling *was* used for catching cast errors in the very >> early versions of this patch (long before I got involved and the >> infrastructure you mention got added). It was taken out after Pavel >> said [1] that he didn't like producing NULL instead of throwing an >> error. Not sure if Pavel's around but it would be good to know why he >> didn't like it at the time. >> > > I'm personally in the "make it error" camp but "make it conform to the standard" is a stronger membership (in general). > > I see this note in your linked thread: > > > 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?
@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 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.
