Re: Triage on old commitfest entries - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Triage on old commitfest entries
Date
Msg-id alpine.DEB.2.22.394.2110040655460.2817726@pseudo
Whole thread Raw
In response to Triage on old commitfest entries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello Tom,

> As I threatened in another thread, I've looked through all of the
> oldest commitfest entries to see which ones should maybe be tossed,
> on the grounds that they're unlikely to ever get committed so we
> should stop pushing them forward to the next CF.


> psql - add SHOW_ALL_RESULTS option    11
>     Last substantive discussion 2021-09, currently passing cfbot
>
>     This got committed and reverted once already.  I have to be
>     suspicious of whether this is a good design.

> Thoughts?

ISTM that the main problem with this patch is that it touches a barely 
tested piece of software, aka "psql":-( The second problem is that the 
initial code is fragile because it handles different modes with pretty 
intricate code.

So, on the first commit it broke a few untested things, among the many 
untested things.

This resulted in more tests being added (sql, tap) so that the relevant 
features are covered, so my point of view is that this patch is currently 
a net improvement both from an engineering perspective and for features 
and enabling other features. Also, there is some interest to get it in.

So I do not think that it deserves to be dropped.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add some tests for pg_stat_statements compatibility verification under contrib
Next
From:
Date:
Subject: RE: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented