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

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? 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? To me it seems like the only required changes
would be to things that know how to parse the output of record_out(),
and there is probably some of that, but the language you're using here
is so emphatic as to make me suspect that you anticipate some larger
impact.

> And the impact wouldn't only be to software that would prefer not
> to know about this. 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. So I guess what you're imagining here is that ALTER TABLE
.. ALTER TYPE would try COERCION_PATH_COERCEVIAIO, but, uh so what? We
could probably fix it so that such coercions were handled in some
other way, but even if we didn't, it just means the user has to
provide a USING clause, which is no different than what happens in any
other case where coerce-via-I/O doesn't work out.

--
Robert Haas
EDB: http://www.enterprisedb.com