From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Robert Haas <robertmhaas@gmail.com>,
        "Jonathan S. Katz" <jkatz@postgresql.org>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Andrew Dunstan <andrew@dunslane.net>,
        Michael Paquier <michael@paquier.xyz>,
        John Naylor <john.naylor@enterprisedb.com>,
        Amit Langote <amitlangote09@gmail.com>
Subject: Re: SQL/JSON features for v15
In-reply-to: <20220823183014.hxdmvjxhy6pnykrc@awork3.anarazel.de>
References: <20220816021425.5sa6gx67zmpou3bc@awork3.anarazel.de>
 <8d0ffc54-469a-ffab-68a3-8b547e24a08d@postgresql.org>
 <7d83684b-7932-9f29-400b-0beedfafcdd4@postgrespro.ru>
 <69022273-e7e3-6d1a-10f8-d1b4740e4b97@postgresql.org>
 <92cab50c-152b-84fc-fd49-12b936113a3d@postgresql.org>
 <CA+TgmoaAZq6rRdVA65PBXBKs=jUHhf42Jf78kBLOaX3c6J7MfQ@mail.gmail.com>
 <20220823155511.ffyntlyjl6wrgljv@awork3.anarazel.de>
 <CA+TgmoZ9E2VoYNFJjw4G0E=+0E+Qs8d1MKuELd9ywaVSW67LQQ@mail.gmail.com>
 <20220823172350.djc7u76hdgyh3v4c@awork3.anarazel.de>
 <718874.1661275730@sss.pgh.pa.us>
 <20220823183014.hxdmvjxhy6pnykrc@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 23 Aug 2022 11:30:14 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <768040.1661284460.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Aug 2022 15:54:20 -0400
Message-ID: <768041.1661284460@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/768041.1661284460%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
>> I agree with the upthread comments that we only need/want to catch
>> foreseeable incorrect-input errors, and that the way to make that
>> happen is to refactor the related type input functions, and that
>> a lot of the heavy lifting for that has been done already.

> I think it's a good direction to go in. What of the heavy lifting for th=
at has
> been done already? I'd have guessed that the hard part is to add differe=
nt,
> optional, type input, type coercion signatures, and then converting a lo=
t of
> types to that?

I was assuming that we would only bother to do this for a few core types.
Of those, at least the datetime types were already done for previous
JSON-related features.  If we want extensibility, then as Robert said
there's going to have to be work done to create a common API that type
input functions can implement, which seems like a pretty heavy lift.
We could get it done for v16 if we start now, I imagine.

			regards, tom lane