Jeff Davis wrote:
> > > Extensions often need to be updated for a new major version.
> >
> > I think forcing the C locale is not comparable to API changes,
> > and the consequences are not even necessarily fixable for extensions.
>
> Are we in agreement that it's fine for C extensions?
No, I think we should put the database's lc_ctype
into LC_CTYPE and the database's lc_collate into
LC_COLLATE, independently of anything else,
like it was done until commit 5e6e42e.
I believe that's the purpose of these database
properties, whether the provider is libc or ICU or builtin.
Forcing "C" is a disruptive change, that IMO does
not seem compensated by substantial advantages
that would justify the disruption.
> > CREATE FUNCTION lt_test(text,text) RETURNS boolean as $$
> > use locale; return ($_[0] lt $_[1])?1:0;
> > $$ LANGUAGE plperlu;
> >
> > select lt_test('a', 'B');
>
> Are you aware of PL code that does things like that? If the database
> locale is ICU, that would be at least a little bit confusing.
plperl users writing "use locale" should understand that
it's the libc locale, like when this code is run outside Postgres.
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
