On Tue, Jul 09, 2024 at 04:20:12PM -0700, Jeff Davis wrote: > On Mon, 2024-07-08 at 18:05 -0700, Noah Misch wrote: > > I'm thinking about these > > aggravating factors for $SUBJECT: > > This is still marked as an open item for 17, but you've already > acknowledged[1] that no code changes are necessary in version 17.
Later posts on the thread made that obsolete. The next step is to settle the question at https://postgr.es/m/20240706195129...@rfd.leadboat.com. If that conclusion entails a remedy, v17 code changes may be part of that remedy. > The idea that you're arguing against is "stability within a PG major > version". There's no new discovery here: it was listed under the > heading of "Benefits" near the top of my initial proposal[2] Thanks for that distillation. More specifically, I'm arguing against the lack of choice about instability across major versions: | ICU collations | pg_c_utf8 ----------------------------------|-------------------|---------- Corruption within a major version | packager's choice | no Corruption at pg_upgrade time | packager's choice | yes I am a packager who chooses no-corruption (chooses stability). As a packager, the pg_c_utf8 stability within major versions is never a bad thing, but it does not compensate for instability across major versions. I don't want a future in which pg_c_utf8 is the one provider that integrity-demanding pg_upgrade users should not use. > and known to all reviewers. If after https://postgr.es/m/20240706195129...@rfd.leadboat.com and https://postgr.es/m/20240709010545.8c.nmi...@google.com they think $SUBJECT should continue as-committed, they should vote that way. Currently, we have multiple votes in one direction and multiple votes in the other direction. If all three reviewers were to vote in the same direction (assuming no other new votes), I argue that such a count would render whichever way they vote as the conclusion. Does that match your count? > [1] > https://www.postgresql.org/message-id/20240701230352.2c.nmi...@google.com > [2] > https://www.postgresql.org/message-id/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.ca...@j-davis.com
