On Mon Jul 3, 2023 at 9:21 AM CDT, Peter Eisentraut wrote:
> On 03.07.23 15:21, Tristan Partin wrote:
> >>> I think it would be better to keep HAVE_LOCALE_T as encompassing any of
> >>> the various locale_t-using functions, rather than using HAVE_USELOCALE
> >>> as a proxy for them. Otherwise you
On 03.07.23 15:21, Tristan Partin wrote:
I think it would be better to keep HAVE_LOCALE_T as encompassing any of
the various locale_t-using functions, rather than using HAVE_USELOCALE
as a proxy for them. Otherwise you create weird situations like having
#ifdef HAVE_WCSTOMBS_L inside #ifdef HAVE
On 03.07.23 08:24, Thomas Munro wrote:
I propose[1] that we get rid of HAVE_LOCALE_T completely and make
"libc" provider support unconditional. It's standardised, and every
target system has it, even Windows. But Windows doesn't have
uselocale().
[1]
https://www.postgresql.org/message-id/flat
On Mon Jul 3, 2023 at 1:24 AM CDT, Thomas Munro wrote:
> On Mon, Jul 3, 2023 at 6:13 PM Peter Eisentraut wrote:
> > On 27.06.23 17:02, Tristan Partin wrote:
> > > This is a patch which implements an issue discussed in bug #17946[0]. It
> > > doesn't fix the overarching issue of the bug, but merely
On Mon, Jul 3, 2023 at 6:13 PM Peter Eisentraut wrote:
> On 27.06.23 17:02, Tristan Partin wrote:
> > This is a patch which implements an issue discussed in bug #17946[0]. It
> > doesn't fix the overarching issue of the bug, but merely a consistency
> > issue which was found while analyzing code b
On 27.06.23 17:02, Tristan Partin wrote:
This is a patch which implements an issue discussed in bug #17946[0]. It
doesn't fix the overarching issue of the bug, but merely a consistency
issue which was found while analyzing code by Heikki. I had originally
submitted the patch within that thread, b
