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.

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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: SQL/JSON query functions context_item doc entry and type requirement
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: 001_rep_changes.pl fails due to publisher stuck on shutdown