Solaris 10 ships with 5.8.4.. Solaris 11 and 11.1 with 5.12 . Solaris 10 is supported by Oracle through at least 2015 (GA + 10 years), possibly 2018. Mind you I don't know what hardware will run 10 native by 2015 since all the old Sun hw goes EOSL by end of 2014 but there are certainly virtual machines supporting 10 long-term.
-----Original Message----- From: "Greg Sabino Mullane" <[email protected]> Date: Tue, 1 Oct 2013 15:10:19 To: <[email protected]> Cc: <[email protected]>; <[email protected]> Subject: Re: Major change approaching - what to add? -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Perl will probably need to be 5.8.4 (or at least 5.8.1) for sane unicode. > > Those versions are targeted by the tool-chain per The Lancaster Consensus: > https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.md Thanks for that link. Forgot about those. Tom Christiansen recommends at least 5.12. That may be too far however. Anyone know of a page that lists the current installed Perl on the major distros? > Perhaps some of your maintainers could work through and close, merge, > update etc as appropriate. Thanks, David. I think the queue is in pretty fair shape. Almost everything important is patched or waiting-for-input. > Is there a detailed description somewhere of "big UTF-8 change"? We no longer selectively apply the utf8 flag to data returned based on the user flipping a awitch plus analysis of the strings bit. We simply check the client_encoding and flip the switch for everything as needed. The old flag is kept around for a bit more control and backwards compatibility. The most details we have at the moment is the docs for the pg_enable_utf8 atribute: pg_enable_utf8 (integer) DBD::Pg specific attribute. The behavior of DBD::Pg with regards to this flag has changed as of version 3.0.0. The default value for this attribute, -1, indicates that the internal Perl "utf8" flag will be turned on for all strings coming back from the database if the client_encoding is set to 'UTF8'. Use of this default is highly encouraged. If your code was previously using pg_enable_utf8, you can probably remove mention of it entirely. If this attribute is set to 0, then the internal "utf8" flag will *never* be turned on for returned data, regardless of the current client_encoding. If this attribute is set to 1, then the internal "utf8" flag will *always* be turned on for returned data, regardless of the current client_encoding (with the exception of bytea data). Note that the value of client_encoding is only checked on connection time. If you change the client_encoding to/from 'UTF8' after connecting, you can set pg_enable_utf8 to -1 to force DBD::Pg to read in the new client_encoding and act accordingly. - -- Greg Sabino Mullane [email protected] End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201310011107 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlJK5akACgkQvJuQZxSWSsg1vwCgt+0HL5+d8Cxa7YaMJr69Bm9n f5IAoJPjgVGLjL0GhG8k0gB/0uBCXjkQ =fihe -----END PGP SIGNATURE-----
