Обсуждение: Postgresql Windows build and modern perl (>=5.28)

Collegues,

Postgresql embeded perl, plperl contain code long time ago copied
from POSIX.xs file in the perl distribution.
It is function setlocale_perl, which does some allocation of
perl-specific locale data using functions(or macros) new_ctype,
new_collate and new_numeric.

This is used only for WIN32, because as comment in the code said:

   /*
     * The perl library on startup does horrible things like call
     * setlocale(LC_ALL,""). We have protected against that on most platforms
     * by setting the environment appropriately. However, on Windows,
     * setlocale() does not consult the environment, so we need to save the
     * existing locale settings before perl has a chance to mangle them and
     * restore them after its dirty deeds are done.
     *
     * MSDN ref:
     * http://msdn.microsoft.com/library/en-us/vclib/html/_crt_locale.asp
     *
     * It appears that we only need to do this on interpreter startup, and
     * subsequent calls to the interpreter don't mess with the locale
     * settings.
     *
     * We restore them using setlocale_perl(), defined below, so that Perl
     * doesn't have a different idea of the locale from Postgres.
     *
     */


This worked up to perl 5.26. But in perl 5.28 these macros and
corresponding functions became strictly private. However public
function Perl_setlocale appeared in libperl, which from the quick
glance to the code does the same thing as setlocale_perl in plperl code.

Attached patch makes use of this function if PERL_VERSION >= 28. 
It makes plperl compile with ActiveStatePerl 5.28 and StrawberryPerl
5.30.2.1.

However, I'm not sure that I've choose correct approach. May be perl
just no more does horrible things with locale at startup?

-- 

Victor Wagner <vitus@wagner.pp.ru> writes:

> Attached patch makes use of this function if PERL_VERSION >= 28. 
> It makes plperl compile with ActiveStatePerl 5.28 and StrawberryPerl
> 5.30.2.1.

I have no opinion on the substantive content of this patch, but please
don't just check against just PERL_VERSION.  Now that Perl 6 has been
renamed to Raku, Perl may bump its major version (PERL_REVISION) to 7 at
some point in th future.

The correct thing to use is the PERL_VERSION_(GT|GE|LE|LT|EQ|NE) macros,
which are provided by newer versions of perl.  We would need to update
the included copy of ppport.h to get them on older perls, but we should
do that anyway, it's not been updated since 2009.  I'll start a separate
thread for that.

- ilmari

Hi,

On 2021-10-04 23:08:25 +0100, Dagfinn Ilmari Mannsåker wrote:
> Victor Wagner <vitus@wagner.pp.ru> writes:
> 
> > Attached patch makes use of this function if PERL_VERSION >= 28. 
> > It makes plperl compile with ActiveStatePerl 5.28 and StrawberryPerl
> > 5.30.2.1.
> 
> I have no opinion on the substantive content of this patch, but please
> don't just check against just PERL_VERSION.  Now that Perl 6 has been
> renamed to Raku, Perl may bump its major version (PERL_REVISION) to 7 at
> some point in th future.

How about the attached? I've just spent more time looking at plperl than I
really ever want to, so I'd like to get plperl working and tested on 5.32 on
windows asap... And this is one of the two fixes necessary (see [1] for the
second).

Greetings,

Andres Freund

[1] https://www.postgresql.org/message-id/20220130221659.tlyr2lbw3wk22owg%40alap3.anarazel.de