Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> 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
