From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Andres Freund <andres@anarazel.de>,
        Alexander Korotkov <aekorotkov@gmail.com>,
        Robert Haas <robertmhaas@gmail.com>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        Corey Huinker <corey.huinker@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Joe Conway <mail@joeconway.com>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Error-safe user functions
In-reply-to: <2b1e7d56-6f37-bad9-9702-053ab55ecf60@dunslane.net>
References: <4009543.1670422833@sss.pgh.pa.us>
 <6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@dunslane.net>
 <CAKFQuwYdQqQru9tpMpY4JpCEJ8OeN8kwmBG6DY2QyzE+5znA6Q@mail.gmail.com>
 <4111458.1670444176@sss.pgh.pa.us> <3211.1670452341@sss.pgh.pa.us>
 <20221207233518.sudtaxn6omtvpzvr@awork3.anarazel.de>
 <186288.1670517119@sss.pgh.pa.us>
 <CA+TgmoZOhQ8FfWH9_r58tLtb=AwBn=7ugO2PHh6moR8jhYviUA@mail.gmail.com>
 <20221208215836.3naznqmal2m32hzc@awork3.anarazel.de>
 <512551.1670540229@sss.pgh.pa.us>
 <20221209023351.l362yejerfoq3lfp@awork3.anarazel.de>
 <633426.1670554790@sss.pgh.pa.us>
 <01ff2051-806d-af2f-4f9e-793f7ba9a3f8@dunslane.net>
 <778369.1670598993@sss.pgh.pa.us>
 <5aaf7c66-9df9-21a9-1ff4-02c7848def52@dunslane.net>
 <3bac9841-fe07-713d-fa42-606c225567d6@dunslane.net>
 <1436686.1670701118@sss.pgh.pa.us>
 <2b1e7d56-6f37-bad9-9702-053ab55ecf60@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Sat, 10 Dec 2022 18:11:35 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1545654.1670716813.1@sss.pgh.pa.us>
Date: Sat, 10 Dec 2022 19:00:13 -0500
Message-ID: <1545655.1670716813@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1545655.1670716813%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2022-12-10 Sa 14:38, Tom Lane wrote:
>> Seeing that SQL/JSON is one of the major drivers of this whole project,
>> it seemed a little sad to me that jsonb couldn't manage to implement
>> what is required.  So I spent a bit of time poking at it.  Attached
>> is an extended version of your patch that also covers jsonb.

> Many thanks for doing this, it looks good.

Cool, thanks.  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.  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.

			regards, tom lane