Re: ON ERROR in json_query and the like
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Markus Winand <markus.winand@winand.at>,
Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-06-21T01:00:48Z
Lists: pgsql-hackers
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. Given that we have "expression IS JSON" the ability to hack together a case expression to get non-erroring behavior exists. David J.
Commits
-
SQL/JSON: Document behavior when input document is not jsonb
- 473a352fb393 17.0 landed
-
SQL/JSON: Correctly enforce the default ON EMPTY behavior
- 03ec20316411 17.0 landed
-
Create infrastructure for "soft" error reporting.
- d9f7f5d32f20 16.0 cited