From: Ian B. <ia...@co...> - 2004-11-30 18:01:32
|
Max Ischenko wrote: >>> Most modern dbs and python drivers handle this problem transparently. >>> At least, that's my experience. >> >> Can you show an example? Using a snippet of code, with a DB API >> driver... > > > Guess not. ;-) > > Just checked with psycopg -- it does requre a parameter to be encoded > into something like utf-8. > > Either my memory make me a disservice or this psycopg is somehow broken. > ;-) I suspect it's something about Unicode in databases being a pain in the ass. At least, that's what I'm guessing; I've never tried to do it, I've only stored ASCII and stuff that I treat as though its binary data. I might note when I installed postgres on Debian, it asked me questions about encoding. This might imply that encoding setup in an installation-wide (not per-database or per-session) fashion. Then it also asked me about how I wanted to format my dates. I answered ISO, but what madness would happen if someone selected US format dates? I doubt psycopg knows anything about what format date the server is using. Maybe these are just defaults, and by explicitly setting up the configuration for the connection you can avoid the madness. So maybe Unicode is like dates, messy and ad hoc. It might be better (or worse) in database servers that accept basic data types; psycopg does all its quoting on the client side. Also, if you are willing to use a default encoding, you could change converters.StringLikeConverter: def UnicodeConverter(value, db): return StringLikeConverter(value.encode('utf-8'), db) registerConverter(unicode, UnicodeConverter) You'll still have to decode strings as they come out of the database, but this will handle any queries you build. Probably the current behavior of using StringLikeConverter for unicode strings is bad, or at least not helpful, because you'll get all sorts of errors if you have any non-ASCII characters. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |