Inheritance in Postgresql and column key references

Question

What happens to downstream rows depending on a PK (via col id) when that PK row changes ID, but not it's value? Think a row deleted and recreated, etc.)

There is a post here that I was reading for another issue, and yet another issue I have can be illustrated by a small portion of what @Guiik posted:

create table parties (
 party_id serial primary key
);
create table individuals (
 party_id int primary key references parties(party_id),
 given_name text,
 ...
);
create table organizations (
 party_id int primary key references parties(party_id),
 organization_name text,
 ...
);

scenario:

1. A row in parties is deleted, and then recreated (possibly simply moved to another table). It will now have a different party_id. Tables individuals and organizations have rows tied to parties' primary_id column.

How can the 'link' between the tables be restored during or after the deletion and recreation?

context:

I'm in a similar situation, but I thought that using a string for a PK value would allow the renaming/renumbering of the id column to not affect table key relationships, being mindful to only have one occurrence in the parent table.

This may look like a silly question at first, but due to volume, I am worried about column numbering 'rolling over', in addition to the situation above, and hoping String keys would be best in current and larger operations between tables, schema, and DBs. I've been using PG for many years, but this is my first attempt to managing up to a billion or so rows...

TIA!

Mods: I know you guys are strict about only allowing simple questions with simple answers, so I really tried to make this as succinct as possible. If I failed to meet your standards, I'm OK with you deleting it.

• Laurenz Albe: That won't work. But why do you want to delete a row and then add it again?
• Lennart - Slava Ukraini: Are you aware that there are actions (ON UPDATE and ON DELETE) on a foreign key? If you don't specify them, default actions are used. In short, they either prevent operations on a parent row, or Cascade the action to the child rows. postgresql.org/docs/current/…
• Yumi Koizumi: Thanks, @Lennart-SlavaUkraini! I'm not yet implementing foreign keys, but have the tables to do so set up. I see now the benefit of doing so. Thanks!
• Lennart - Slava Ukraini: In your example you have foreign keys (references creates a foreign key)