Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\))
Subject: Re: PostgreSQL 15.9 Update: Partitioned tables with foreign key
 constraints
From: Paul Foerster <paul.foerster@gmail.com>
In-Reply-To: <202411191634.vexoqghfj2aq@alvherre.pgsql>
Date: Tue, 19 Nov 2024 20:16:28 +0100
Cc: pgsql-general list <pgsql-general@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C978240A-915E-4AAA-B665-CB1630A11E7D@gmail.com>
References: <202411191634.vexoqghfj2aq@alvherre.pgsql>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Archived-At: <https://www.postgresql.org/message-id/C978240A-915E-4AAA-B665-CB1630A11E7D%40gmail.com>
Precedence: bulk

Hi Alvaro,

> On 19 Nov 2024, at 17:34, Alvaro Herrera <alvherre@alvh.no-ip.org> =
wrote:
>=20
> It doesn't really matter when you do it, because the constraint only
> gets broken by running DETACH with the old server code.  You have
> already run the DETACH sometime in the past (that's how the constraint
> got broken), which means you would not run it again now to the same
> table.  The old server code will behave correctly when doing ADD / =
DROP
> constraint, as will the new server code.  Feel free to run it when =
it's
> more convenient to you.

Thanks.

> I'd advise against running ALTER TABLE DETACH until you have upgraded,
> however -- at least, for partitioned tables that have foreign keys
> pointing to other partitioned tables.

I have no influence on that. It's a third party application. In fact, I =
can't even do much about the applications developed inhouse because =
they're too big. That means, if there is anything built into an =
application, then it takes many moons to get it out again.

Cheers,
Paul