Re: [PATCH] ecpg: fix progname memory leak

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [PATCH] ecpg: fix progname memory leak
Дата
Msg-id CABUevEy84MQRvSJ=yVeBo_KXEe84mHEDFsGsoXDU1i7Mz9Sktw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] ecpg: fix progname memory leak  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: [PATCH] ecpg: fix progname memory leak  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Expansion of our checks for connection-loss errors