From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | 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-04 20:58:51 |
Message-ID: | CA+hUKGLZ1aTgDp6ZHb+H66mQ3E_d=q5f0Q9_a3+P1RvOyBNQWA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 5, 2019 at 4:18 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> On Mon, Nov 4, 2019 at 11:13 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > > Here are some problems to think about:
> > >
> > > * We'd need to track dependencies on the default collation once we
> > > have versioning for that [...]
>
> Another problem I just thought about is how to avoid discrepancy of
> collation version for indexes on shared objects, such as
> pg_database_datname_index.
I didn't look closely at the code, but I think when "name" recently
became collation-aware (commit 586b98fd), it switched to using
C_COLLATION_OID as its typcollation, and "C" doesn't need versioning,
so I think it would only be a problem if there are shared catalogs
that have "name" columns that have a non-type-default collation.
There are none of those, and you can't create them, right? If there
were, if we take this patch set to its logical conclusion, we'd also
need pg_shdepend.refobjversion, but we don't need it AFAICS.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-11-04 21:15:43 | Re: Collation versioning |
Previous Message | Tom Lane | 2019-11-04 20:55:46 | Re: patch: psql - enforce constant width of last column |