Horton

Re: Collation version tracking for macOS

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>, Thomas Munro <thomas.munro@gmail.com>
Cc: "Finnerty, Jim" <jfinnert@amazon.com>, "Nasby, Jim" <nasbyj@amazon.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jeremy Schneider <schneider@ardentperf.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-06-14T18:10:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix copy&paste typo in comment

On 11.06.22 05:35, Peter Geoghegan wrote:
> Do we even need to store a version for indexes most of the time if
> we're versioning ICU itself, as part of the "time travelling
> collations" design? For that matter, do we even need to version
> collations directly anymore?

Conversely, why are we looking at the ICU version instead of the 
collation version.  If we have recorded the collation as being version 
1234, we need to look through the available ICU versions (assuming we 
can load multiple ones somehow) and pick the one that provides 1234.  It 
doesn't matter whether it's the same ICU version that the collation was 
originally created with, as long as the collation version stays the same.