On Sep 8, 2008, at 20:42, Bill Moseley wrote:
Ok, how formal would you need?
I guess my proposal would be to perhaps have a flag that when set
causes DBD::Pg to read the client_encoding after making a connection.
Then use that encoding with Encode::encode() and Encode::decode() when
moving data between Perl and Pg.
Frankly, I think that this should be a part of the DBI. But note that
some databases have different encodings on different columns.
The implementation details are a bit more sketchy. ;)
For one thing, I'm not sure if the client_encoding returned from Pg
would match with the encoding names used by Perl.
Should be do-able.
Then, would also need to know what data should and should not be
decoded and encoded. I guess everything except binary (and numeric?)
column data.
I think only text types and text-like types (Greg, how does DBD::Pg
determine this, currently? I'd want CITEXT data to be converted to
UTF-8, too; is there some way to tell it what types should be utf8?)
But, the current system seems to work fine -- someone can simply use
utf8 client encoding and set pg_enable_utf8 (regardless of their
database's encoding). And it's unlikely that Perl's internal
representation of character data will change from utf8 anytime soon
so just forcing the utf8 flag is fine.
Yep.
Best,
David
