On Thu, Apr 25, 2024 at 5:05 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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. > > What I'm trying to say is: given that the command "alter type T alter > attribute A type foo" exists, users would reasonably expect the system > to honor that on its own for any composite type, because that's what > it does today. But it can't if T has custom I/O functions, at least > not without understanding how to rewrite those functions.
I understand your point, but I don't agree with it. Ordinary users wouldn't be able to create types like this anyway, because there's no way we can allow an unprivileged user to set an input or output function. It would have to be restricted to superusers, just as we do for base types. And IMHO those have basically the same issue: you have to ensure that all the functions and operators that operate on the type, and any subscripting operations, are on the same page about what the underlying storage is. This doesn't seem different. It may well still be a bad idea for other reasons, or just kind of useless, but I disagree that it's a bad idea for that particular reason. > Nope, it isn't IMO. We already added infrastructure to allow > arbitrary custom types to define subscripting operations. I think a > case could be made to allow them to define field selection, too. That would be cool! > I take it that you also don't believe that "2 + 3 * 4" should yield > different results from "(2 + 3) * 4"? Isaac's rebuttal to this particular point was perfect; I have nothing to add. -- Robert Haas EDB: http://www.enterprisedb.com
