Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-19T01:06:26Z
Lists: pgsql-hackers
On Fri, Jan 18, 2019 at 4:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I thought that your ALTER OBJECT DEPENDS ON EXTENSION example made the > > case for fixing that directly inarguable. I'm slightly surprised that > > you're not fully convinced of this already. Have I missed some > > subtlety? > > It's clear that we must change *something* in that area. I'm not yet > wedded to a particular fix, just expressing a guess as to what might > be the cleanest fix. I'm surprised that you're not "wedded" to that fix in some sense, though. Your analysis about the right design having one DEPENDENCY_INTERNAL dependency on the partition master index, and one DEPENDENCY_AUTO dependency on the matching partitioned table seemed spot on to me. > Also, we evidently need something we can back-patch into v11, which might > end up being very far from clean :-(. I have no opinions yet on what > would make sense in that branch. Me neither, but, as I said, I think that you've identified the right design for the master branch. And, I tend to doubt that you'll find something that works for the backbranches that is also worth using in the master branch. Why does it seem necessary to fix the bug in the backbranches? I agree that it's broken, but it's not obvious to me that it'll cause serious problems in the real world that outweigh the potential downsides. Perhaps I've missed some obvious downside. -- Peter Geoghegan
Commits
-
Redesign the partition dependency mechanism.
- 1d92a0c9f7dd 12.0 landed
-
Fix trigger drop procedure
- cc126b45ea5c 11.2 landed
- cb90de1aac18 12.0 landed
-
Sort the dependent objects before recursing in findDependentObjects().
- f1ad067fc3ae 12.0 landed
-
Avoid sometimes printing both tables and their columns in DROP CASCADE.
- 9194c4270b28 12.0 landed