Re: insensitive collations

	Jim Finnerty wrote:

> Currently nondeterministic collations are disabled at the database level. 

Deterministic ICU collations are also disabled.

> The cited reason was because of the lack of LIKE support and because certain
> catalog views use LIKE. 

But the catalogs shouldn't use the default collation of the database.

commit 586b98fdf1aaef4a27744f8b988479aad4bd9a01 provides
some details about this:

Author: Tom Lane 
Date:	Wed Dec 19 17:35:12 2018 -0500

    Make type "name" collation-aware.

    The "name" comparison operators now all support collations, making them
    functionally equivalent to "text" comparisons, except for the different
    physical representation of the datatype.  They do, in fact, mostly share
    the varstr_cmp and varstr_sortsupport infrastructure, which has been
    slightly enlarged to handle the case.

    To avoid changes in the default behavior of the datatype, set name's
    typcollation to C_COLLATION_OID not DEFAULT_COLLATION_OID, so that
    by default comparisons to a name value will continue to use strcmp
    semantics.	(This would have been the case for system catalog columns
    anyway, because of commit 6b0faf723, but doing this makes it true for
    user-created name columns as well.	In particular, this avoids
    locale-dependent changes in our regression test results.)

    In consequence, tweak a couple of places that made assumptions about
    collatable base types always having typcollation DEFAULT_COLLATION_OID.
    I have not, however, attempted to relax the restriction that user-
    defined collatable types must have that.  Hence, "name" doesn't
    behave quite like a user-defined type; it acts more like a domain
    with COLLATE "C".  (Conceivably, if we ever get rid of the need for
    catalog name columns to be fixed-length, "name" could actually become
    such a domain over text.  But that'd be a pretty massive undertaking,
    and I'm not volunteering.)

    Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite