Re: Replication vs. float timestamps is a disaster

On 2/22/17 7:56 AM, Andres Freund wrote:
> On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> On 2017-02-22 00:10:35 -0600, Jim Nasby wrote:
>>>> I wounder if a separate "floatstamp" data type might fit the bill there. It
>>>> might not be completely seamless, but it would be binary compatible.
>>> I don't really see what'd that solve.
>> Seems to me this is a different name for what I already tried in
>> <27694(dot)1487456324(at)sss(dot)pgh(dot)pa(dot)us>. It would be much better than doing
>> nothing, IMO, but it would still leave lots of opportunities for mistakes.
> 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. 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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)