On 2017-02-22 09:06:38 -0600, Jim Nasby wrote: > On 2/22/17 7:56 AM, Andres Freund wrote: > > It sounded more like Jim suggested a full blown SQL type, given that he > > replied to my concern about the possible need for a deprecation period > > due to pg_upgrade concerns. To be useful for that, we'd need a good > > chunk of magic, so all existing uses of timestamp[tz] are replaced with > > floattimestamp[tz], duplicate some code, add implicit casts, and accept > > that composites/arrays won't be fixed. That sounds like a fair amount > > of work to me, and we'd still have no way to remove the code without > > causing pain. > > Right, but I was thinking more in line with just providing the type (as an > extension, perhaps not even in core) and making it possible for pg_upgrade > to switch fields over to that type.
Isn't the above what you'd need to do that? > That would allow an in-place upgrade of > a really large cluster. A user would still need to modify their code to use > the new type. > > Put another way: add ability for pg_upgrade to change the type of a field. > There might be other uses for that as well. Type oids are unfortunately embedded into composite and array type data - we can do such changes for columns themselves, but it doesn't work if there's any array/composite members containing the to-be-changed type that are used as columns. - Andres -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers