Re: Error-safe user functions
От | Andrew Dunstan |
---|---|
Тема | Re: Error-safe user functions |
Дата | |
Msg-id | 3bac9841-fe07-713d-fa42-606c225567d6@dunslane.net обсуждение исходный текст |
Ответ на | Re: Error-safe user functions (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Error-safe user functions
Re: Error-safe user functions |
Список | pgsql-hackers |
On 2022-12-09 Fr 10:37, Andrew Dunstan wrote: > I am currently looking at the json types. I think that will be enough to > let us rework the sql/json patches as discussed a couple of months ago. > OK, json is a fairly easy case, see attached. But jsonb is a different kettle of fish. Both the semantic routines called by the parser and the subsequent call to JsonbValueToJsonb() can raise errors. These are pretty much all about breaking various limits (for strings, objects, arrays). There's also a call to numeric_in, but I assume that a string that's already parsed as a valid json numeric literal won't upset numeric_in. Many of these occur several calls down the stack, so adjusting everything to deal with them would be fairly invasive. Perhaps we could instead document that this class of input error won't be trapped, at least for jsonb. We could still test for well-formed jsonb input, just as I propose for json. That means that we would not be able to trap one of these errors in the ON ERROR clause of JSON_TABLE. I think we can probably live with that. Thoughts? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: