Re: ON ERROR in json_query and the like
От | Markus Winand |
---|---|
Тема | Re: ON ERROR in json_query and the like |
Дата | |
Msg-id | A64C1F9D-5BE9-486F-A0A3-32927D50DDEA@winand.at обсуждение исходный текст |
Ответ на | Re: ON ERROR in json_query and the like ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: ON ERROR in json_query and the like
|
Список | pgsql-hackers |
> On 21.06.2024, at 07:38, David G. Johnston <david.g.johnston@gmail.com> wrote: > > On Thursday, June 20, 2024, Markus Winand <markus.winand@winand.at> wrote: > > > > On 21.06.2024, at 06:46, David G. Johnston <david.g.johnston@gmail.com> wrote: > >> > > > > > 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? > > > Hearsay. > > https://www.postgresql.org/message-id/CAFj8pRCnzO2cnHi5ebXciV%3DtuGVvAQOW9uPU%2BDQV1GkL31R%3D-g%40mail.gmail.com > > > 4) If ALREADY PARSED is False, then it is implementation-defined whether the > > following rules are applied: > > a) The General Rules of Subclause 9.36, "Parsing JSON text", are applied with > > JT as JSON TEXT, an implementation-defined <JSON key uniqueness constraint> > > as UNIQUENESS CONSTRAINT, and FO as FORMAT OPTION; let ST be the STATUS and > > let CISJI be the SQL/JSON ITEM returned from the application of those > > General Rules. > > b) If ST is not successful completion, then ST is returned as the STATUS of > > this application of these General Rules, and no further General Rules of > > this Subclause are applied. > > But maybe I’m mis-interpreting that snippet and Nikita’s related commentary regarding have chosen between options for thisimplementation-defined feature. Ah, here we go. Nowadays this is called IA050, “Whether a JSON context item that is not of the JSON data type is parsed.”(Likewise IA054 “Whether a JSON parameter is parsed.”) So updating the three options: > 1. Disallow anything but jsonb for context_item (the patch I posted yesterday) * Non-conforming * patch available > 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. * Conforming by choosing IA050 to implement GR4: raise errors independent of the ON ERROR clause. * currently committed. > 3. Go ahead and fix implicit casts to jsonb so that any parsing errors > respect ON ERROR (no patch written yet). * Conforming by choosing IA050 not to implement GR4: Parsing happens later, considering the ON ERROR clause. * no patch available, not trivial I guess I’m the only one in favour of 3 ;) My remaining arguments are that Oracle and Db2 (LUW) do it that way and also thatit is IMHO what users would expect. However, as 2 is also conforming (how could I miss that?), proper documentation isa very tempting option. -markus ps: Does anyone know a dialect that implements GR4?
В списке pgsql-hackers по дате отправления: