On Jul 3, 2013, at 1:10 PM, Tim Bunce <[email protected]> wrote: > It would be worth mentioning the PGCLIENTENCODING env var in the docs, > and the fact that it can be set to "auto" to "determine the right > encoding from the current locale in the client (LC_CTYPE environment > variable on Unix systems)."
Probably not a good idea, IMHO, as if you want text decoded into Perl strings, it has to be UTF-8. > The doc says "for all strings coming back" which is possibly a little > ambiguous. > > (After poking about in the code and libpq docs I'm wondering if > PQfformat() should be used to confirm that a field is "textual" > before applying SvUTF8_on.) See https://rt.cpan.org/Ticket/Display.html?id=40199#txn-541858. *Everything* delivered by libPQ should be text. That ticket has a lot of discussion on this issue, if you’re interested in background, as does this thread: http://www.nntp.perl.org/group/perl.dbd.pg/2011/07/msg603.html A bit long, though. > Ideally the docs would have a section on Unicode that discusses it in > relation to SQL statements, placeholders, attributes (like $sth->{NAME}), > array stringification and error messages. I.e. at least all the places > that have SvUTF8/_on/_off() calls, plus anywhere that character data > gets passed into libpq. +1 >> A lot of this is not going to have any perfect answers, especially as far >> as backwards compatibilty goes, and forward compatibility with DBI >> support. But we need to get moving, and I think this is a pretty good >> first effort. > > I agree, and I'm delighted to this. +100. Been wanting this for *years* (above RT ticket starts in 2008). > p.s. How can I subscribe to the commits mailing list? From the headers of the post I replied to: List-Subscribe: <mailto:[email protected]> Best, David
