Re: cutting down the TODO list thread

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cutting down the TODO list thread
Date: 2020-12-17 14:58:58
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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.

> 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:
> 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:


> *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.


> - 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.


Bruce Momjian <bruce(at)momjian(dot)us>

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-12-17 15:02:57 Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Previous Message Konstantin Knizhnik 2020-12-17 14:54:28 Re: libpq compression