From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Dilip Kumar <dilipbalaut@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Why don't we support external input/output functions for the composite types
In-reply-to: <CA+TgmoYWa1tFpAKD+pV6H65wfc=nDpcVYNKN5TMxq3pwGBGEkA@mail.gmail.com>
References: <CAFiTN-uiwaogH-dbz-ARpUUQM+RQKdU2qmPh1WzM6gEyS8PVRA@mail.gmail.com> <3833077.1714020280@sss.pgh.pa.us> <CA+TgmoZfQcftzZsQFOhGmeD59qhKmNMR_ROWphmsFXeY=YYb9w@mail.gmail.com> <3952020.1714062859@sss.pgh.pa.us> <CA+TgmoZ9pGaY7MzdAYbOZ1Sab3be-kpW+muDw68ro5va3-yEfA@mail.gmail.com> <3998496.1714079132@sss.pgh.pa.us> <CA+TgmoYWa1tFpAKD+pV6H65wfc=nDpcVYNKN5TMxq3pwGBGEkA@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 26 Apr 2024 10:34:30 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <4174965.1714146957.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Apr 2024 11:55:57 -0400
Message-ID: <4174966.1714146957@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/4174966.1714146957%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 25, 2024 at 5:05=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wro=
te:
>> What I'm trying to say is: given that the command "alter type T alter
>> attribute A type foo" exists, users would reasonably expect the system
>> to honor that on its own for any composite type, because that's what
>> it does today.  But it can't if T has custom I/O functions, at least
>> not without understanding how to rewrite those functions.

> I understand your point, but I don't agree with it. Ordinary users
> wouldn't be able to create types like this anyway, because there's no
> way we can allow an unprivileged user to set an input or output
> function. It would have to be restricted to superusers, just as we do
> for base types.

Well, that would be one way of making the consistency problem be not
our problem, but it would be a sad restriction.  It'd void a lot of
the arguable use-case for this feature, if you ask me.  I realize
that non-superusers couldn't create the C-language I/O functions that
would be most at risk here, but you could imagine people building
I/O functions in some other PL.

(We'd have to remove the restriction that cstring isn't an allowed
input or return type for user-defined functions; but AFAIK that's
just a holdover from days when cstring was a lot more magic than
it is now.)

Maybe there's an argument that PL functions already have to be
proof enough against datatype inconsistencies that nothing really
awful could happen.  Not sure.

In any case, if we have to put strange restrictions on a composite
type when it has custom I/O functions, then that still is an
indication that the feature is a hack that doesn't play nice
with the rest of the system.  So I remain of the opinion that
we shouldn't go there.  If field selection support for custom
types will solve the use-case, I find that a lot more attractive.

>> I take it that you also don't believe that "2 + 3 * 4" should yield
>> different results from "(2 + 3) * 4"?

> Isaac's rebuttal to this particular point was perfect; I have nothing to=
 add.

As far as I could tell, Isaac's rebuttal was completely off-point.

			regards, tom lane