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? 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
