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: