| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | "Finnerty, Jim" <jfinnert(at)amazon(dot)com>, "Nasby, Jim" <nasbyj(at)amazon(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Collation version tracking for macOS |
| Date: | 2022-06-11 04:08:41 |
| Message-ID: | CAH2-Wzm3vvuGZ5epNeaAFGpAeRDZPBGkGFYSz+YKay9Zp7LKgg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 10, 2022 at 8:47 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> I'm also suspicious that there are more subtle hazards like pathkeys
> lurking in the shadows. We go to great effort to recognise matching
> and non-matching collations by OID alone, which is why my first
> attempt was "distinct [OIDs]", so that'd keep working.
It's definitely possible that we won't be able to find a workable
solution that deals with "time travel collations" sensibly from the
planner's perspective. It's certainly not a neat adjunct to what we
have. I think that it *might* be possible to find a way to make it
work that is suboptimal, but works. Without being overly clever.
The DB2 docs say "use the CLDR version prefix to avoid unexpected
changes in behavior when upgrading to future releases of the Db2
database". But if you don't do that, and get a change in behavior,
then surely any related indexes must have been rebuilt too. The
interesting part may be what that upgrade looks like in detail.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2022-06-11 04:20:44 | Re: Collation version tracking for macOS |
| Previous Message | Thomas Munro | 2022-06-11 04:07:48 | Re: Collation version tracking for macOS |