Re: [HACKERS] Replication vs. float timestamps is a disaster - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] Replication vs. float timestamps is a disaster
Date
Msg-id 8ac3b446-00e0-2813-e67a-0498fac0f9b0@BlueTreble.com
Whole thread Raw
In response to Re: [HACKERS] Replication vs. float timestamps is a disaster  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Replication vs. float timestamps is a disaster  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List 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)



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] Replication vs. float timestamps is a disaster