Re: cutting down the TODO list thread

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 <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee