Re: Error-safe user functions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Error-safe user functions
Date
Msg-id 2b137e09-2313-3985-691f-8d8f4ba8473f@dunslane.net
Whole thread Raw
In response to Re: Error-safe user functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser)
Next
From: Joseph Koshakow
Date:
Subject: Date-Time dangling unit fix