On Thu, Dec 10, 2020 at 03:29:07PM -0400, John Naylor wrote: > Hi, I agree with all of your analysis, but have some feedback;
> Continuing with TODO list maintenance, first a couple things to clean up: > > - Allow ALTER INDEX ... RENAME concurrently > > This was in the wrong section, but it's irrelevant: The lock level was lowered > in commit 1b5d797cd4f, so I went ahead and removed this already. Good. > > - Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT > > The link titled "how not to write this patch" points to a web archive of the > author's description of how he implemented the rejected patch. That doesn't > seem useful, since it was...rejected. I propose to replace that with the > -hackers thread, where there is discussion of the design problem: > https://www.postgresql.org/message-id/flat/ > CAJZSWkWN3YwQ01C3%2Bcq0%2BeyZ1DmK%3D69_6vryrsVGMC%3D%2BfWrSZA%40mail.gmail.com > > Now, for the proposed items to move to "Not Worth Doing". As before, let me > know of any objections. I plan to move these early next week: Agreed. > *Views and Rules > > - Allow VIEW/RULE recompilation when the underlying tables change > > The entry itself says "This is both difficult and controversial." and the > linked threads confirm that. Yes, probably shouldn't be an item. > > - Make it possible to use RETURNING together with conditional DO INSTEAD > rules, > such as for partitioning setups > > This was from before we got native partitioning, so the stated rationale is > outdated. I don't think we need that anymore. > *SQL Commands (this is a huge section, for now just doing the miscellany at > the > top before the various subsections) > > - Add a GUC variable to warn about non-standard SQL usage in queries > > I don't see the reason for this, and sounds difficult anyway. It is hard. > - Add NOVICE output level for helpful messages > > This would only be useful if turned on, so is going to be least used where it > might help the most. It also sounds like a lot of slow menial work to > implement. It is menial work, but I thought it might inspire someone to do it. Removal at this point seems fine. > - Allow DISTINCT to work in multiple-argument aggregate calls > > Tom suggested this in 2006 for the sake of orthogonality. Given the amount of > time passed, it seems not very important. Yes. > - Allow DELETE and UPDATE to be used with LIMIT and ORDER BY > > Some use cases mentioned, but nearly all have some kind of workaround already. Agreed. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
