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


Reply via email to