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