Re: Error-safe user functions
От | Andrew Dunstan |
---|---|
Тема | Re: Error-safe user functions |
Дата | |
Msg-id | 2b137e09-2313-3985-691f-8d8f4ba8473f@dunslane.net обсуждение исходный текст |
Ответ на | Re: Error-safe user functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2022-12-10 Sa 19:00, Tom Lane wrote: > Looking at my notes, there's one other loose end > I forgot to mention: > > * Note: pg_unicode_to_server() will throw an error for a > * conversion failure, rather than returning a failure > * indication. That seems OK. > > We ought to do something about that, but I'm not sure how hard we > ought to work at it. Perhaps it's sufficient to make a variant of > pg_unicode_to_server that just returns true/false instead of failing, > and add a JsonParseErrorType for "untranslatable character" to let > json_errdetail return a reasonably on-point message. Seems reasonable. > We could imagine > extending the ErrorSaveContext infrastructure into the encoding > conversion modules, and maybe at some point that'll be worth doing, > but in this particular context it doesn't seem like we'd be getting > a very much better error message. The main thing that we would get > from such an extension is a chance to capture the report from > report_untranslatable_char. But what that adds is the ability to > identify exactly which character couldn't be translated --- and in > this use-case there's always just one. > > Yeah, probably overkill for now. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: