Alvaro Herrera writes:
> I notice that some information_schema view columns end up with C
> collation after this patch, and others remain with default collation.
> Is that sensible? (I think the only two cases where this might matter
> at all are information_schema.parameters.parameter_name,
> in
On 2018-Dec-15, Tom Lane wrote:
> I wrote:
> > While fooling with the idea of making type "name" collation
> > aware, it occurred to me that there's a better, more general
> > answer, which is to insist that collation-aware system catalog
> > columns must be marked with C collation.
> Concretely,
I wrote:
> While fooling with the idea of making type "name" collation
> aware, it occurred to me that there's a better, more general
> answer, which is to insist that collation-aware system catalog
> columns must be marked with C collation. This rule would apply
> without modification to both "te
Awhile back we noticed that a couple of system catalogs had
acquired indexes on "text" columns, which were unsafe because
their sort order was collation-dependent, so that cloning
template0 with a different database collation could yield
broken indexes. We fixed this in commit 0b28ea79 with a
bit
