Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10
| От | Nathan Bossart |
|---|---|
| Тема | Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10 |
| Дата | |
| Msg-id | adaQ4-kOoIi6FGYs@nathan обсуждение |
| Ответ на | Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10 (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10
|
| Список | pgsql-hackers |
On Wed, Apr 08, 2026 at 12:42:21PM -0400, Andrew Dunstan wrote: > On 2026-04-08 We 12:23 PM, Tom Lane wrote: >> I'm on board with this for v20, but as a matter of reviewing the >> patch: it'd be easier if you separated it into two steps, one that >> does the actual changes but doesn't reindent anything, and then a >> separate application of pgindent. As this diff stands, there's an >> awful lot of noise resulting from outdenting no-longer-conditional >> code, which has to be reviewed by hand but it could be checked >> mechanically if you left it to a "this just applies pgindent" step. Will do. There's also various code consolidation throughout, so I suspect this will become ~3 patches in the end. >> Looking at the commit log, I was struck by my comment in 30e7c175b: >> >> (As in previous changes of >> this sort, we aren't removing pg_restore's ability to read older >> archive files ... though it's fair to wonder how that might be >> tested nowadays.) >> >> I wonder whether we ought to sunset some of that code too, and >> if so how to draw the line on minimum archive version to support. K_VERS_1_12 was added in 2010 for v9.0, and K_VERS_1_13 was added in 2018 for v11. The latter is within our 10 release window for pg_dump, etc., and the former is well beyond it. So, K_VERS_1_12 is probably the latest we could bump it to. I suspect that'd be fine, but we might still want to consider choosing an earlier version out of an abundance of caution. Perhaps our policy could be something like past-15-major-releases for pg_restore. >> BTW, see also 492046fa9. Noted. > I'm on board, if for no other reason than that it will shorten some of my > animals' buildfarm runs. I guess people wanting to upgrade from ancient > versions can do it in multiple hops. At the same time, I wouldn't want to do > this every year. It's been 5 years since he last time we did this, and that > seems about the right interval. Yeah, I think this is where we ultimately landed in a previous discussion on Discord. -- nathan
В списке pgsql-hackers по дате отправления: