| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Douglas Doole <dougdoole(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Collation versioning |
| Date: | 2019-11-27 21:09:57 |
| Message-ID: | CA+TgmoZSCjinh6Sfoofp2tfweFvQxXoCUNv+dyJnS6PzNGv_LA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 26, 2019 at 3:44 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> I suppose another reason to use such a switch would be if there is a
> change in the versioning scheme; for example, as of today in master we
> are using the glibc version, but a future glibc release might offer an
> interface to query the CLDR version it's using, and then a future
> release of PostgreSQL might get support for that, so the strings would
> change between major version of PostgreSQL but you might want to be
> able to tell pg_upgrade that your indexes are good.
Yeah, I like #3 too. If we're going to the trouble to build all of
this mechanism, it seems worth it to build the additional machinery to
be precise about the difference between "looks like a problem" and "we
don't know".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2019-11-27 21:36:50 | Re: FETCH FIRST clause WITH TIES option |
| Previous Message | Robert Haas | 2019-11-27 19:57:27 | Re: WIP/PoC for parallel backup |