On Jul 21, 2011, at 4:23 PM, David Christensen wrote: >> I disagree. It's me telling DBD::Pg what encoding the database uses, but I >> definitely want that converted to Perl's internal form. I *only* want raw if >> I explicitly ask for raw (or if there's no choice, such as when I set the >> encoding to ":raw" or something). > > As a developer, why would you care if this information is available from the > database itself? If you are caring about the encoding at all, you would be > dealing with bytes/octets. Perl does not store unicode characters in any > format besides UTF-8 so you're not changing "internal" characteristics ; what > DBD::Pg uses to talk to your database shouldn't matter.
Because otherwise what's the point? I could just turn pg_unicode off. >> I think of it being kind of like the `encdoding` pragma, in which I declare >> the encoding of my source code. Perl sees that and converts it to its >> internal form. > > The only time this would be useful would be if your database is set to > something inscrutable (aka SQL_ASCII); if your end result is meant to be > internal perl, you have no business providing an encoding. You are convincing me now that pg_encoding may not be useful at all, then. >> I wonder if, as an interrime measure, existing code that sets pg_enable_utf8 >> should still do something, like set pg_encoding to "utf-8" and turn >> pg_unicode on. > > Yeah, I'd had that thought, along with spitting the deprecation warning. Right, I think that'd be the least painful thing for users. > Yeah, it'd be nice to know what at least some proposed interfaces/APIs are so > we don't need to support a whole other place setting for years to come. +1 Best, David
