Re: cutting down the TODO list thread

On Tue, May 16, 2023 at 1:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:

> >> Add support for polymorphic arguments and return types to languages
other than PL/PgSQL
> >> Add support for OUT and INOUT parameters to languages other than
PL/PgSQL

> > These actually seem like pretty interesting projects.
>
> Yeah. I'm surprised that nobody has gotten around to scratching
> this itch yet.

Okay, keeping these.

On Tue, May 16, 2023 at 3:50 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:
>
> On 2023-May-13, John Naylor wrote:

> > Consider having single-page pruning update the visibility map

> Hmm, I agree with removing the entry from the TODO list, but why is this
> something we Do Not Want? If somebody shows up and do some analysis
> that in a certain workload it is beneficial to do this, then I don't
> think we should turn them down.

Okay, removing but not adding to Do Not Want.

On Tue, May 16, 2023 at 8:52 PM Matthias van de Meent <
boekewurm+postgres(at)gmail(dot)com> wrote:
>
> On Tue, 16 May 2023 at 14:27, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Tue, May 16, 2023 at 8:18 AM Matthias van de Meent
> > <boekewurm+postgres(at)gmail(dot)com> wrote:
> > > Agreed; and that's why I'm not against removing the specific wording
> > > of the item. This may not have been clearly described in my previous
> > > mail, but I would instead like to see a TODO list item which covers
> > > the need to improve the number of cases where we provide actionable
> > > advice, and specifically those cases where there is not One Obvious
> > > Issue (OOI;s like when getting close to wraparound; or close
> > > checkpoints, or ...).
> >
> > My vote is for just removing the item, rather than putting it on the
> > not wanted list. I don't think it's useful to put things as general as
> > what you say here on the list. But putting this item in the not wanted
> > section might imply that it's not an area we're looking to improve,
> > which as you say, is false.
>
> That makes sense. Agreed.

(This was for SET PERFORMANCE_TIPS) -- removing but not adding to Do Not
Want.

I've removed all else proposed to simply remove.

Also removing "ECPG - Fix nested C comments" as done.

As for this:

On Sat, May 13, 2023 at 12:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> > Improve speed of tab completion
> > -> Is this still a problem?
>
> I keep worrying that tab-complete.c will become so ungainly as to
> present a human-scale performance problem. But there's been pretty
> much zero complaints so far. Let's drop this one until some actual
> issue emerges.

Looking in the thread, the issue has to do with catalog queries, and in
fact I must have fat-fingered copying the entry -- it should be "Improve
speed of tab completion by using LIKE":

http://www.postgresql.org/message-id/20120821174847.GL1267@tamriel.snowman.net

I've left it alone for now just in case.

(I have yet to think about concrete revisions that seem needed, but I'll do
that separately.)

--
John Naylor
EDB: http://www.enterprisedb.com