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

On Mon, Feb 6, 2023 at 11:04 AM John Naylor <john.naylor@enterprisedb.com> wrote:
> I'll try to get back to culling the list items at the end of April.

I've made another pass at this. Previously, I went one or two sections at a time, but this time I tried just skimming the whole thing and noting what jumps out at me. Also, I've separated things into three categories: Remove, move to "not wanted list", and revise. Comments and objections welcome, as always.

---------------------------------
1. Remove

These are either ill-specified, outdated, possibly done already, or not enough interest. If someone proposed them again, we could consider it, so I propose to just remove these, but not move them to the Not Wanted list. Also some questions:

Improve UTF8 combined character handling?
-> If this is referring to normalization, we have it now. If not, what needs improving?

Improve COPY performance
-> What's the criterion for declaring this done? There are many areas that get performance improvements -- why does this need to be called out separately? (There's been some work in the past couple years, so maybe at least we need to find out the current bottlenecks.)

Improve line drawing characters
-> This links to a proposal with no responses titled "Add a setting in psql that set the linestyle to unicode only if the client encoding was actually UTF8". If we don't drop this, the entry text should at least give an idea what the proposal is.

Consider improving the continuation prompt
-> A cosmetic proposal that stalled -- time to retire it?

SMP scalability improvements
-> Both threads are from 2007

Consider GnuTLS if OpenSSL license becomes a problem
-> We now have the ability to swap in another implementation during the build process

Allow creation of universal binaries for Darwin
-> From 2008: Is this still a thing?

Allow plug-in modules to emulate features from other databases
-> This sounds like a hook or extension.

Rethink our type system
-> Way out of scope, and short on details.

Add support for polymorphic arguments and return types to languages other than PL/PgSQL
-> Seems if someone needed this, they would say so (no thread).

Add support for OUT and INOUT parameters to languages other than PL/PgSQL
-> Ditto

--------------------
2. Propose to move to the "Not Wanted list":

(Anything already at the bottom under the heading "Features We Do Not Want", with the exception of "threads in a single process". I'll just remove that -- if we ever decide that's worth pursuing, it'll be because we decided we can't really avoid it anymore, and in that case we surely don't need to put it here.)

Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER
-> There are external tools that help with this kind of analysis

Allow regex operations in PL/Perl using UTF8 characters in non-UTF8 encoded databases
-> Seems pie-in-the-sky as well as a niche problem?

Add option to print advice for people familiar with other databases
-> Doesn't seem relevant anymore?

Consider having single-page pruning update the visibility map
-> Comment from Heikki in the thread:
"I think I was worried about the possible performance impact of having to
clear the bit in visibility map again. If you're frequently updating a
tuple so that HOT and page pruning is helping you, setting the bit in
visibility map seems counter-productive; it's going to be cleared soon
again by another UPDATE. That's just a hunch, though. Maybe the overhead
is negligible."