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

From Erik Rijkers
Subject Re: Triage on old commitfest entries - JSON_PATH
Date
Msg-id 35ca891f-bd10-3994-aa83-494de3a43ea7@xs4all.nl
Whole thread Raw
In response to Triage on old commitfest entries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Triage on old commitfest entries - JSON_PATH
Re: Triage on old commitfest entries - JSON_PATH
List pgsql-hackers
Op 03-10-2021 om 21:14 schreef Tom Lane:
> 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.
> 
> An important note to make here is that we don't have any explicit
> mechanism for saying "sorry, this patch is perhaps useful but it
> seems that nobody is going to take an interest in it".  Closing
> such a patch as "rejected" seems harsh, but R-W-F isn't very
> appropriate either if the patch never got any real review.
> Perhaps we should create a new closure state?
> 
> I looked at entries that are at least 10 CFs old, as indicated by
> the handy sort field.  That's a pretty small population: 16 items
> out of the 317 listed in the 2021-09 CF.  A quick look in recent
> CFs shows that it's very rare that we commit entries older than
> 10 CFs.
> 
> Here's what I found, along with some commentary about each one.
> 
> Patch        Age in CFs

May I add one more?

SQL/JSON: JSON_TABLE started 2018 (the commitfest page shows only 4 as 
'Age in CFs' but that obviously can't be right)

Although I like the patch & new functionality and Andrew Dunstan has 
worked to keep it up-to-date, there seems to be very little further 
discussion. I makes me a little worried that the time I put in will end 
up sunk in a dead project.


Erik Rijkers

> 
> Protect syscache from bloating with negative cache entries    23
>     Last substantive discussion 2021-01, currently passing cfbot
> 
>     It's well known that I've never liked this patch, so I can't
>     claim to be unbiased.  But what I see here is a lot of focus
>     on specific test scenarios with little concern for the
>     possibility that other scenarios will be made worse.
>     I think we need some new ideas to make progress.
>     Proposed action: RWF
> 
> Transactions involving multiple postgres foreign servers    18
>     Last substantive discussion 2021-07, currently failing cfbot
> 
>     This has been worked on fairly recently, but frankly I'm
>     dubious that we want to integrate a 2PC XM into Postgres.
>     Proposed action: Reject
> 
> schema variables, LET command    18
>     Last substantive discussion 2021-09, currently passing cfbot
> 
>     Seems to be actively worked on, but is it ever going to get
>     committed?
> 
> Remove self join on a unique column    16
>     Last substantive discussion 2021-07, currently passing cfbot
> 
>     I'm not exactly sold that this has a good planning-cost-to-
>     usefulness ratio.
>     Proposed action: RWF
> 
> Index Skip Scan    16
>     Last substantive discussion 2021-05, currently passing cfbot
> 
>     Seems possibly useful, but we're not making progress.
> 
> standby recovery fails when re-replaying due to missing directory which was removed in previous replay    13
>     Last substantive discussion 2021-09, currently passing cfbot
> 
>     This is a bug fix, so we shouldn't drop it.
> 
> Remove page-read callback from XLogReaderState    12
>     Last substantive discussion 2021-04, currently failing cfbot
> 
>     Not sure what to think about this one, but given that it
>     was pushed and later reverted, I'm suspicious of it.
> 
> Incremental Materialized View Maintenance    12
>     Last substantive discussion 2021-09, currently passing cfbot
> 
>     Seems to be actively worked on.
> 
> pg_upgrade fails with non-standard ACL    12
>     Last substantive discussion 2021-03, currently passing cfbot
> 
>     This is a bug fix, so we shouldn't drop it.
> 
> Fix up partitionwise join on how equi-join conditions between the partition keys are identified    11
>     Last substantive discussion 2021-07, currently passing cfbot
> 
>     This is another one where I feel we need new ideas to make
>     progress.
>     Proposed action: RWF
> 
> A hook for path-removal decision on add_path    11
>     Last substantive discussion 2021-03, currently passing cfbot
> 
>     I don't think this is a great idea: a hook there will be
>     costly, and it's very unclear how multiple extensions could
>     interact correctly.
>     Proposed action: Reject
> 
> Implement INSERT SET syntax    11
>     Last substantive discussion 2020-03, currently passing cfbot
> 
>     This one is clearly stalled.  I don't think it's necessarily
>     a bad idea, but we seem not to be very interested.
>     Proposed action: Reject for lack of interest
> 
> SQL:2011 application time    11
>     Last substantive discussion 2021-10, currently failing cfbot
> 
>     Actively worked on, and it's a big feature so long gestation
>     isn't surprising.
> 
> WITH SYSTEM VERSIONING Temporal Tables    11
>     Last substantive discussion 2021-09, currently failing cfbot
> 
>     Actively worked on, and it's a big feature so long gestation
>     isn't surprising.
> 
> 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.
> 
> Split StdRdOptions into HeapOptions and ToastOptions    10
>     Last substantive discussion 2021-06, currently failing cfbot
> 
>     I think the author has despaired of anyone else taking an
>     interest here.  Unless somebody intends to take an interest,
>     we should put this one out of its misery.
>     Proposed action: Reject for lack of interest
> 
> 
> Thoughts?
> 
>             regards, tom lane
> 
> 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Triage on old commitfest entries
Next
From: Platon Pronko
Date:
Subject: Re: very long record lines in expanded psql output