Re: Broken defenses against dropping a partitioning column - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Broken defenses against dropping a partitioning column
Date
Msg-id 11607.1563822144@sss.pgh.pa.us
Whole thread Raw
In response to Re: Broken defenses against dropping a partitioning column  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Broken defenses against dropping a partitioning column  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
I wrote:
> Here's a proposed patch for that.  It's mostly pretty straightforward,
> except I had to add some recursion defenses in findDependentObjects that
> weren't there before.  But those seem like a good idea anyway to prevent
> infinite recursion in case of bogus entries in pg_depend.
> Per above, I'm envisioning applying this to HEAD and v12 with a catversion
> bump, and to v11 and v10 with no catversion bump.

Pushed.  Back-patching turned up one thing I hadn't expected: pre-v12
pg_dump bleated about circular dependencies.  It turned out that Peter
had already installed a hack in pg_dump to suppress that complaint in
connection with generated columns, so I improved the comment and
back-patched that too.

I nearly missed the need for that because of all the noise that
check-world emits in pre-v12 branches.  We'd discussed back-patching
eb9812f27 at the time, and I think now it's tested enough that doing
so is low risk (or at least, lower risk than the risk of not seeing
a failure).  So I think I'll go do that now.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Add CREATE DATABASE LOCALE option
Next
From: Tom Lane
Date:
Subject: Re: initdb recommendations