Re: [HACKERS] Replication vs. float timestamps is a disaster
| От | Andrew Dunstan | 
|---|---|
| Тема | Re: [HACKERS] Replication vs. float timestamps is a disaster | 
| Дата | |
| Msg-id | f733bd4c-fd12-29c1-83c0-1c8073bd970b@2ndQuadrant.com обсуждение исходный текст | 
| Ответ на | Re: [HACKERS] Replication vs. float timestamps is a disaster (Jim Nasby <Jim.Nasby@BlueTreble.com>) | 
| Ответы | Re: [HACKERS] Replication vs. float timestamps is a disaster | 
| Список | pgsql-hackers | 
On 02/22/2017 10:21 AM, Jim Nasby wrote: > 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. No, in the datums. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: