Re: [SQLObject] bug with UnicodeCol

[Ian B. <ia...@co...>]

Stuart Bishop wrote:
> Is there actually a use case for allowing each column to have a
> different encoding? 

Probably not.  Though there's probably a use case for every database 
connection to have a different encoding.

> I know for PostgreSQL it is simply a matter of
> setting the database encoding to Unicode and sending everything as UTF-8
> by simply encoding the entire query (which takes care of other issues
> like Unicode column names as well). The only use cases I can come up
> with for your scenario should be usng BINARY columns instead of VARCHAR
> - - in particular, since the database doesn't know the encoding you are
> using then all your basic string operations, sorting etc. are now broken.

This suggests we should do it in a way that we allow Unicode-aware 
databases to get Unicode data directly, and other databases use 
transparent encoding.

> Hmm... perhaps if you need to store text in some encoding that doesn't
> contain the ASCII character set it might be necessary, but I don't know
> what character sets these are or if any databases actually support them.
> I've gone through the list of encodings PostgreSQL supports and they all
> contain the basic latin letters and can be used to encode SQL
> statements, so I suspect this is not a requirement.

That seems overly aggressive.  It just feels very wrong to encode the 
entire query.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org