From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Replication vs. float timestamps is a disaster
Date: Wed, 22 Feb 2017 09:06:38 -0600
Message-ID: <49985f09-7498-9a84-008b-638cbaebb044@BlueTreble.com> (raw)
In-Reply-To: <20170222135634.gnlqu6by2xbpvwii@alap3.anarazel.de>
References: <26788.1487455319@sss.pgh.pa.us>
<CA+TgmoafyUzmg8T-rKEgmkX7F1iQLSrKBmqKa26EattXpMS-ng@mail.gmail.com>
<1691.1487519369@sss.pgh.pa.us>
<20170220070311.gscn7ppqbwlgdpjq@alap3.anarazel.de>
<3bd3c551-8b23-45c8-27a2-97b5a922b130@2ndquadrant.com>
<20170220110456.2jupmfhxlizykmmc@alap3.anarazel.de>
<fece0003-6ede-ca8b-8f26-3c6fa899583d@BlueTreble.com>
<20170222075345.mbzrmdaetdqfgitk@alap3.anarazel.de>
<21041.1487771008@sss.pgh.pa.us>
<20170222135634.gnlqu6by2xbpvwii@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2/22/17 7:56 AM, Andres Freund wrote:
> On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
>> Andres Freund <andres@anarazel.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.1487456324@sss.pgh.pa.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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: Jim.Nasby@BlueTreble.com, andres@anarazel.de, tgl@sss.pgh.pa.us, petr.jelinek@2ndquadrant.com, robertmhaas@gmail.com
Subject: Re: Replication vs. float timestamps is a disaster
In-Reply-To: <49985f09-7498-9a84-008b-638cbaebb044@BlueTreble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox