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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.