Re: Why don't we support external input/output functions for the composite types

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> This thread caught my eye this morning, and I'm confused.
> On Thu, Apr 25, 2024 at 12:44 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The primary outcome would be to require a huge amount of new work
>> to be done by a lot of software, much of it not under our control.

> What, what is the "lot of software" that would have to be changed?

I think this potentially affects stuff as low-level as drivers,
particularly those that deal in binary not text I/O. It's not
unreasonable for client code to assume that any type with
typtype 'c' (composite) will adhere to the specifications at
https://www.postgresql.org/docs/current/rowtypes.html#ROWTYPES-IO-SYNTAX
especially because that section pretty much says in so many words
that that's the case.

> It
> can't be existing extensions, because they wouldn't be forced into
> using this feature. Are you thinking that drivers or admin tools would
> need to support it?

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.

>> For example, how likely do you think it is
>> that these hypothetical user-defined I/O functions would cope
>> well with ALTER TABLE/ALTER TYPE commands that change those
>> rowtypes?

> Hmm. Dilip mentioned changing the storage format, but if you do that,
> you have bigger problems, like my_record_type.x no longer working. At
> that point I don't see why what you have is properly called a record
> type at all.

Yup, I agree.

> So I guess what you're imagining here is that ALTER TABLE
> .. ALTER TYPE would try COERCION_PATH_COERCEVIAIO, but, uh so what?

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.

You could imagine preventing such trouble by forbidding ALTER TYPE
on types with custom I/O functions. But that just makes it even
more obvious that what this is is a poorly-thought-through hack,
rather than a feature that interoperates well with the rest of
Postgres.

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.

regards, tom lane