Re: [PATCH] ecpg: fix progname memory leak - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [PATCH] ecpg: fix progname memory leak
Date
Msg-id CABUevEy84MQRvSJ=yVeBo_KXEe84mHEDFsGsoXDU1i7Mz9Sktw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] ecpg: fix progname memory leak  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: [PATCH] ecpg: fix progname memory leak  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


On Fri, Oct 9, 2020 at 1:08 PM John Naylor <john.naylor@enterprisedb.com> wrote:

On Fri, Oct 9, 2020 at 4:47 AM Daniel Gustafsson <daniel@yesql.se> wrote:
Now, I don't actually suggest we *remove* it, as there is valuable curated
content, but that we rename it to something which won't encourage newcomers to
pick something from the list simply because it exists.  The name "TODO" implies
that the list is something which it isn't.
 
+1

+1 as well. The way things are today, that is a terrible name, and has been for a double-digit number of years.


The name is very much at odds with the content. To pick one baffling example, there's an entry under Free Space Map that dates to before the on-disk FSM was invented. A more accurate, if not charitable, description is "archive of stalled discussions". This is just a side effect of non-controversial todos getting finished over time. That could be helped with a round of aggressive culling.


That is one very good example indeed.


Also, it's organized by functionality, which makes sense in a way, but I don't find very useful in this context. Better categories might be

help-wanted, 
good-first-issue (I know this is a tough one), 
feature-request, 
won't-fix (The memory leaks under discussion go here, it seems),  
code-cleanup, 
research-project, 
documentation, 
performance, 
user-experience, 
sql-standard 
etc. 

I suspect we will eventually want something like a full-blown issue tracker, although I gather that's been rejected previously. But a wiki page is not really suited for this.

Talk about "possibly controversial proposal" eh?

That said, having this in a different format would in no way fix the fact that the information is mislabeled and obsolete.  It would likely be equally mislabeled and obsolete in an issue tracker. Just look at almost any of the other projects out there that *do* use an issue tracker and have been around for 20+ years.

That said, I am a believer in that we should have one, yes. But I am equally certain that it would not help with *this* particular problem.

--

pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
Next
From: Tom Lane
Date:
Subject: Re: Expansion of our checks for connection-loss errors