Re: Add Unicode Support to the DBI

"David E. Wheeler" <[email protected]>
Newsgroups gmane.comp.lang.perl.modules.dbi.sybase.devel
Message-ID <[email protected]>
On Oct 6, 2011, at 8:56 AM, Greg Sabino Mullane wrote:

>> I still prefer an encoding attribute that you can set as follows:
> 
>> * undef: Default; same as your A.
>> * ':utf8': Same as your B:
>> * ':raw': Same as your C
>> * $encoding: Encode/decode to/from $encoding
> 
> I like that. Although the names are still odd.

I think what I haven't said is that we should just use the same names that Perl I/O uses. Er, well, for the :raw and :utf8 varieties I was, anyway. Perhaps we should adopt it wholesale, so you'd use ":encoding(UTF-8)" instead of "UTF-8".

Some details on the PerlIO names is here:

  https://metacpan.org/module/open

I'm sure there's a more detailed description somewhere, though I couldn't find it.

> I guess it does map 
> though: raw means no utf8 flag.

Right. And the default would be either :raw or :utf8, and should probably be left to the DBD (depending on the importance of backward compatibility vs. trying to DTRT).

> Still not sure about the encode 
> 'to', but I'll start thinking about how we could implement the 
> 'from' in DBD::Pg.

For DBD::Pg, at least, if client-encoding is set to Big5, then you *have* to encode to send it to the database. Or change the client encoding, of course.

> How would one map things - just demand that 
> whatever is given must be a literal encoding the particular database 
> can understand?

I think we should standardize on the Perl IO names for these things. Some databases may not support them all, of course.

>> With an encoding attribute, you don't need the utf8_flag at all.
> 
> Right, +1
> 
> So the above means these two actually behave very differently:
> 
> $dbh->{encoding} = ':utf8';
> 
> $dbh->{encoding} = 'utf8';
> 
> Could be a little confusing, no? Methinks we some long ugly name, maybe 
> even worse than "perl_native". Perhaps "perl_internal_utf8_flag"? 1/2 :)

No, I think just "encoding", and "utf8" would be invalid, but ":encoding(UTF-8)" would not.

> Thanks for plugging away at this. My short term goal is to get this finalized 
> enough that I can release the next version of DBD::Pg without a 'pg_' prefix 
> to control the encoding items.

Well, I think we might have to have it with the pg_prefix until this stuff is finalized here. Not sure, though.

Best,

David
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.