* If we commit 0003, is it a useful feature by itself or does it require that we commit some or all of 0004-0014? Which of these need to be in v18?
Useful by itself.
0004 seems needed to me, unless we're fine with ~50% bloat in pg_class on a new-upgraded system, or we think inplace update are on their way out.
0005 is basically theoretical, it is only needed if we change the default relpages on partitioned tables.
0006-0011 are the vacuumdb things being debated now. I've reached out to some of the people I spoke to at PgConf.eu to get them to chime in.
0012 is now moot as a similar patch was committed Friday.
0013 is a cleanup/optimization.
0014 is the --no-data flag, which has no meaning without 0004, but 0004 in no way requires it.
* Why does binary upgrade cause statistics to be dumped? Can you just make pg_upgrade specify the appropriate set of flags?
That decision goes back a ways, I tried to dig in the archives last night but I was getting a Server Error on postgresql.org.
Today I'm coming up with https://www.postgresql.org/message-id/267624.1711756062%40sss.pgh.pa.us which is actually more about whether stats import should be the default (consensus: yesyesyes), and the binary_upgrade test may have been because binary_upgrade shuts off data section stuff, but table stats are in the data section. Happy to review the decision.
* It looks like appendNamedArgument() is never called with positional=true?
That is currently the case. Currently all params are called with name/value pairs, but in the past we had leading positionals followed by the stat-y parameters in name-value pairs. I'll be refactoring it to remove the positonal=T/F argument, which leaves just a list of name-type pairs, and thus probably reduces the urge to make it an array of structs.
* It's pretty awkward to use an array of arrays of strings when an array of structs might make more sense.
I'll be rebasing (that's done) and refactoring 0003 to get rid of the positional column, and moving 0014 next to 0003 because they touch the same files.
