Re: ON ERROR in json_query and the like
| От | David G. Johnston |
|---|---|
| Тема | Re: ON ERROR in json_query and the like |
| Дата | |
| Msg-id | CAKFQuwakKgGi_jsmf7fEryx_NV-wiEVdAbUOB8GvD6kAuz+Fyg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: ON ERROR in json_query and the like (Amit Langote <amitlangote09@gmail.com>) |
| Ответы |
Re: ON ERROR in json_query and the like
Re: ON ERROR in json_query and the like |
| Список | 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.
> 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.
В списке pgsql-hackers по дате отправления: