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+TgmoZ9pGaY7MzdAYbOZ1Sab3be-kpW+muDw68ro5va3-yEfA@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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 25 Apr 2024 13:12:39 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <3998495.1714079132.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Thu, 25 Apr 2024 17:05:32 -0400
Message-ID: <3998496.1714079132@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3998496.1714079132%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 25, 2024 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Uh, no.  My point is that if you make a custom output function
>> for "type complex (real float8, imaginary float8)", that function
>> will probably crash pretty hard if what it's handed is something
>> other than two float8s.

> I'm not sure I really buy this. Changing the column definitions
> amounts to changing the on-disk format, and no data type can survive a
> change to the on-disk format without updating the I/O functions to
> match.

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 think that to the extent that there's a need for custom I/O
>> of something like this, it should be handled by bespoke types,
>> similar to (say) type point.

> I somewhat agree with this. The main disadvantage of that approach is
> that you lose the ability to directly refer to the members, which in
> some cases would be quite nice. I bet a lot of people would enjoy
> being able to write my_point.x and my_point.y instead of my_point[0]
> and my_point[1], for example. But maybe the solution to that is not
> $SUBJECT.

Nope, it isn't IMO.  We already added infrastructure to allow
arbitrary custom types to define subscripting operations.  I think a
case could be made to allow them to define field selection, too.

> I think it's confusing and counterintuitive that putting parentheses
> around a subexpression completely changes the meaning. I don't know of
> any other programming language that behaves that way,

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

I could get behind offering an alternative notation, eg "a.b->c does
the same thing as (a.b).c", if we could find a reasonable notation
that doesn't infringe on user operator namespace.  I think that might
be hard to do though, and I don't think the existing notation is so
awful than we should break existing operators to have an alternative.
The business with deprecating => operators a few years ago had the
excuse that "the standard says so", but we don't have that
justification here.


			regards, tom lane