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.fd@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.fd@rfd.leadboat.com and
https://postgr.es/m/20240709010545.8c.nmisch@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.nmisch@google.com
> [2]
> https://www.postgresql.org/message-id/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel@j-davis.com
