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 [EMAIL PROTECTED]
maybe the human race deserves to be wiped out
