On Mon, Sep 08, 2008 at 09:25:17PM -0000, Greg Sabino Mullane wrote: > > > 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. > > I don't honestly remember why things are like they are at the moment, > but we certainly may be doing the things the wrong way. :) Maybe you can > expand the above paragraph into a more formal set of proposed rules. > When I get some time, I'll devote some cycles to this.
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. 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. 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. 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. -- Bill Moseley [EMAIL PROTECTED] Sent from my iMutt
