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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser)
Следующее
От: Joseph Koshakow
Дата:
Сообщение: Date-Time dangling unit fix