On Fri, Feb 14, 2025 at 12:35 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote: > 1) In a previous post you said: > > "Yes, in this scenario the copy is already created, and triggers keep > the copy in sync with the original table." > > In that case the copy will already have TOAST tables associated with it. If we follow the idea behind repack_swap, we would have swapped the oid's of the two tables. This means you have to swap the TOAST table in the catalogue as well. Otherwise the new table will be linked to the old TOAST and the old table will be linked to the new TOAST. We want the opposite. > 2) What are the FK relationships and how many? I think that for theoretical purposes we can just say there are "N" FKs. Because no matter how many there are, they need to be updated to point towards the new table. > Also could you just not add the FK's as NOT VALID? That's an interesting compromise I haven't thought of. Thanks. However, ideally I'd like to swap the catalogue entries instead - as that would be a cleaner approach since it wouldn't require dropping old constraints, creating NOT VALID ones, and then optionally validating them later. Regards, - Marcelo
