Date: Tue, 22 Oct 2024 16:23:12 +0200
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tender Wang <tndrwang@gmail.com>, Junwang Zhao <zhjwpku@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Alexander
 Lakhin <exclusion@gmail.com>, Guillaume Lelarge <guillaume@lelarge.info>,
 Michael Paquier <michael@paquier.xyz>
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Message-ID: <20241022162312.63021cc6@karst>
In-Reply-To: <202410181450.xchtzcq2uyjt@alvherre.pgsql>
References: <20240926104835.07ae9ab5@karst>
	<202410181450.xchtzcq2uyjt@alvherre.pgsql>
Organization: Dalibo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/20241022162312.63021cc6%40karst>
Precedence: bulk

On Fri, 18 Oct 2024 16:50:59 +0200
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> On 2024-Sep-26, Jehan-Guillaume de Rorthais wrote:
>=20
> > REL_14_STABLE backport doesn't seem trivial, so I'll wait for some
> > feedback, review & decision before going further down in backpatching.
>=20
> Hi, thanks for these patches.  I have made some edits of my own.  In the
> end I decided that I quite liked the new structure of the
> addFkConstraint() function and friends.=20

Yes, I especially like the fact that addFkRecurseReferencing() and
addFkRecurseReferenced() have now the same logic/behavior.

> I added a bunch of comments and changed names somewhat.

checked.

> Also, I think the benefit of the refactoring is
> more obvious when all patches are squashed together, so I did that.

OK.

> For branch 14, I opted to make it delete the constraints on detach.
> This isn't ideal but unless somebody wants to spend a lot more time on
> this, it seems the best we can do.  Leaving broken constraints around
> seems worse.=20

Keep that in mind, and move ahead to the next level: self-FK on partitioned
table! ;-)

https://www.postgresql.org/message-id/flat/20230707175859.17c91538%40karst#=
0dc7b8afd8b780899021bbb075598250

> [=E2=80=A6]
>=20
> I spent some time going through your test additions and ended up with
> your functions in this form:
> [=E2=80=A6]
>=20
> However, in the end I think this is a very good technique to verify that
> the fix works correctly, but it's excessive to include these results in
> the tests forevermore.  So I've left them out for now.  Maybe we should
> reconsider on the older branches?

The point here was to make sure futur work/refactoring don't forget/break
anything in the catalog representation of FK on partitions.

Regards,