Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Apr-03, Tom Lane wrote:
>> Actually, thinking about that a bit harder: there's one aspect of
>> what pg_upgrade does that's really hard to control from userspace,
>> and that's forcing tables to have the same OIDs as before. In this
>> context, that means you're probably out of luck if the table has a
>> TOAST table, unless the TOAST table is empty. There wouldn't be
>> any good way to keep TOAST pointers valid across the move.
> Hmm, couldn't you use the binary-upgrade support functions just prior to
> creating the table in the target database?
Yeah, in theory you could do that, if the OID isn't already in use for
a table. But that just added several more steps and more ways to
shoot yourself in the foot. I'm starting to think this wouldn't really
be worth the risk.
regards, tom lane