Horton

Re: Replication vs. float timestamps is a disaster

Jim Nasby <jim.nasby@bluetreble.com>

View thread View on postgr.es
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-02-22T15:21:18Z
Lists: pgsql-hackers 
On 2/22/17 9:12 AM, Andres Freund wrote:
>> 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.

Only in the catalog though, not the datums, right? I would think you 
could just change the oid in the catalog the same as you would for a 
table column.
-- 
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)

Commits

  1. Consistently declare timestamp variables as TimestampTz.

  2. Remove now-dead code for !HAVE_INT64_TIMESTAMP.

  3. Remove pg_control's enableIntTimes field.

  4. De-support floating-point timestamps.

  5. Make integer_datetimes the default for MSVC even if not mentioned in config.pl.

  6. Enable 64-bit integer datetimes by default, per previous discussion.