From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Alexander Korotkov <aekorotkov@gmail.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Andrew Dunstan <andrew@dunslane.net>,
        "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: <20221209023351.l362yejerfoq3lfp@awork3.anarazel.de>
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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 08 Dec 2022 18:33:51 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <633425.1670554790.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Dec 2022 21:59:50 -0500
Message-ID: <633426.1670554790@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/633426.1670554790%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-12-08 17:57:09 -0500, Tom Lane wrote:
>> Given that this additional experimentation didn't find any holes
>> in the API design, I think this is pretty much ready to go.

> One interesting area is timestamp / datetime related code. There's been =
some
> past efforts in the area, mostly in 5bc450629b3. See the RETURN_ERROR ma=
cro in
> formatting.c.
> This is not directly about type input functions, but it looks to me that=
 the
> functionality in the patchset should work.

Yeah, I was planning to take a look at that before walking away from
this stuff.  (I'm sure not volunteering to convert ALL the input
functions, but I'll do the datetime code.)

You're right that formatting.c is doing stuff that's not exactly
an input function, but I don't see why we can't apply the same
API concepts to it.

			regards, tom lane