Robert Haas <robertmh...@gmail.com> writes: > This thread caught my eye this morning, and I'm confused. > On Thu, Apr 25, 2024 at 12:44 AM Tom Lane <t...@sss.pgh.pa.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
