Victor Subervi wrote: > On Fri, Dec 11, 2009 at 8:13 PM, Gabriel Genellina > <gagsl-...@yahoo.com.ar <mailto:gagsl-...@yahoo.com.ar>> wrote: > Are you sure the column is declared as SET and not, say, VARCHAR? > > > yes
Indeed it is, and knowing that, I can actually decode your original post. I apologize that I didn't see the forest for all the trees you gave us. Your problem is that you are inspecting the metadata of a table to find out which possible values can be stored in a particular SET column of a particular table, and when you get the description of the table, you're getting a Python string object that describes the column, rather than a list (or set) of strings. The only solution is the one you already resigned to using, which is to dissect the string into its parts, as confirmed by this article: http://dev.mysql.com/tech-resources/articles/mysql-set-datatype.html . > Anyway, I don't think MySQLdb is able to handle the SET data type > correctly. > > > Oh, lovely! What do? MySQLdb does too handle the SET data type correctly, or at least as correctly as the underlying database itself will allow. It seems that SET-typed values can only be retrieved as strings or integers, and the latter only by "casting" the value to an integer by adding 0 to it. Oh, the humanity! The best advice I can give you is to rethink your data schema and avoid using the SET data type altogether. (Note that I'm only referring to the MySQL data type here. There's nothing wrong with Python's Set type.) The above-mentioned article has a section called "Why you shouldn't use SET." You should read it. HTH, -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
