Re: cutting down the TODO list thread - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: cutting down the TODO list thread
Date
Msg-id 20201217145858.GA23260@momjian.us
Whole thread Raw
In response to Re: cutting down the TODO list thread  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: cutting down the TODO list thread
List pgsql-hackers
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@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

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




pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit