list and now I'm a bit more curious about how DBD::Pg handles
different client encodings. Feel free to point me to any archive if
this is an old topic.
I assume the "pg_enable_utf8" feature was added in 1.22:
1.22 Wed Mar 26 22:33:44 EST 2003 (subversion r6993)
- Add utf8 support [Dominic Mitchell <[email protected]>]
I use the pg_enable_utf8 option -- my database is in utf8 (and thus my
client encoding defaults to utf8). All seems to work well. In my
applications I also decode all input data from other sources (e.g.
templates), and call encode() for all output (except data going to the
From my *limited* knowledge of DBD::Pg it seems the pg_enable_utf8
option simply forces the utf8 flag on data read from the database
*IF* that data looks like a valid utf8 string. Does that happen on
all column data, or only columns that are text?
Are there any other actions by DBD::Pg for supporting character
I didn't see that DBD::Pg does any encoding of data, yet I do not see
any "Wide Character in %s" errors when writing to the db, so I assume
DBD::Pg is sending data to the db in a way that avoids that message.
I'm curious about forcing the utf8 flag because binary data might look
like a valid utf8 string but not be (not that setting the utf8 flag
will do any damage to non-text data, that I'm aware of).
I think the "proper" approach would be to decode using the
client_encoding on read from the db on text columns and likewise
encode to the client encoding on write back to the db. But, perhaps
there is a reason that approach was not taken.
Can anyone fill me in on the state of character support in DBD::Pg?
Sent from my iMutt