public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: Tom Lane <[email protected]>
Cc: Dilip Kumar <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Why don't we support external input/output functions for the composite types
Date: Thu, 25 Apr 2024 13:12:39 -0400
Message-ID: <CA+TgmoZ9pGaY7MzdAYbOZ1Sab3be-kpW+muDw68ro5va3-yEfA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAFiTN-uiwaogH-dbz-ARpUUQM+RQKdU2qmPh1WzM6gEyS8PVRA@mail.gmail.com>
<[email protected]>
<CA+TgmoZfQcftzZsQFOhGmeD59qhKmNMR_ROWphmsFXeY=YYb9w@mail.gmail.com>
<[email protected]>
On Thu, Apr 25, 2024 at 12:34 PM Tom Lane <[email protected]> wrote:
> Yes. We've heard that argument about "this only affects extensions
> that choose to use it" before, and it's nonsense. As soon as you
> extend system-wide APIs, the consequences are system-wide: everybody
> has to cope with the new definition.
Sure. Any new feature has this problem to some extent.
> 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. But there is nothing to stop somebody
> from trying to ALTER the type to be two numerics or whatever.
> Conversely, the type's custom input function would likely keep on
> producing two float8s, yielding corrupt data so far as the rest
> of the system is concerned.
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.
> 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.
A related problem is that, even if my_point behaved like a composite
type, you'd have to write (my_point).x and (my_point).y to avoid
something like:
ERROR: missing FROM-clause entry for table "my_point"
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, and I find the
way the "indirection" productions are coded in gram.y to be highly
questionable. I suspect everything we currently treat as an
indirection_el should instead be a way of constructing a new a_expr or
c_expr or something like that, but I strongly suspect if I try to make
the work I'll discover horrible problems I can't fix. Still, it's
awful.
--
Robert Haas
EDB: http://www.enterprisedb.com
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
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>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox