Re: Questions about pg_enable_utf8
Steve Haslam <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.dbdpg |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Sep 08, 2008 at 08:42:06PM -0700, Bill Moseley wrote: > 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. [...] > 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. So why try to support encodings other than utf8 anyway? IMHO having DBD::Pg setting the client_encoding to 'utf8' if pg_enable_utf8 is specified would make more sense. I suspect that trying to support other encodings is a bit of a minefield, and tbh I'm a bit puzzled as to what exactly the gain would be. SRH -- Steve Haslam Reading, UK araqnid-25+bR1YndWNWk0Htik3J/[email protected] maybe the human race deserves to be wiped out