| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Remaining dependency on setlocale() |
| Date: | 2025-10-31 15:25:46 |
| Message-ID: | a1a184524e11bb4dc8092353a02672cc42a05233.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2025-10-31 at 15:01 +0100, Daniel Verite 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?
> For instance, consider the following function, when run in a database
> with en_US.utf8 as locale.
>
> 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.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2025-10-31 15:36:24 | Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement |
| Previous Message | Tatsuro Yamada | 2025-10-31 15:19:07 | [PATCH] psql: add \dcs to list all constraints |