On Tue, 2024-08-13 at 17:11 +0200, Peter Eisentraut wrote:
> They used to be completely separate from
> pg_newlocale_from_collation(),
> but now they are just mostly a thin wrapper around it. Except there
> is
> some hardcoded handling of C_COLLATION_OID and POSIX_COLLATION_OID.
> Do
> we care about that?
...
> However, it's not clear whether the hardcoded handling of some
> collations is needed for performance parity or perhaps some
> bootstrapping reasons. It would be useful to get that cleared up.
> Thoughts?
There's at least one place where we expect lc_collate_is_c() to work
without catalog access at all: libpq/hba.c uses regexes with
C_COLLATION_OID.
But I don't think that's a major problem -- we can just move the
hardcoded test into pg_newlocale_from_collation() and return a
predefined struct with collate_is_c/ctype_is_c already set.
+1.
Regards,
Jeff Davis
