From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Replication vs. float timestamps is a disaster |
Date: | 2017-02-22 15:12:30 |
Message-ID: | 20170222151230.zy7q7qmfah22lcxt@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2017-02-22 15:13:59 | Re: Make subquery alias optional in FROM clause |
Previous Message | Tom Lane | 2017-02-22 15:08:38 | Re: Make subquery alias optional in FROM clause |