[DB-SIG] Type code mappings: expanding the type objects
mal at egenix.com
Thu Jan 8 06:54:28 EST 2004
Kevin Jacobs wrote:
> On Thu, 8 Jan 2004, Federico Di Gregorio wrote:
>> 3/ BOOLEAN is under NUMBER (this will probably give some problems to
>> postgresql and other db using 't' and 'f' but there is really no
>> simple solution and Python *do* use 1 and 0 for True and False (at
>> least untill 2.3)
> SQL 92 and 99 are very clear that booleans and integers are not
> interchangeable. The Python semantics should not be the driving factor
The question here is what you want to do with the inheritence
information. Most (if not all) database modules return booleans/bits
as 1/0 or True/False, so NUMBER would make sense if you're interested
in what the application will see.
SQL would make them a subclass of STRING.
> I'm somewhat sceptical about the WCHAR versions of STRING types. Python has
> native support for unicode strings, so why maintain this artificial
> distinction? The better solution would be to augment the column description
> format to include character encoding information.
Unicode and strings *are* different in Python and also handled
differently in databases, so the distinction makes a lot of sense,
e.g. strings are often subject to an encoding specified by the
database, while Unicode does not have these deficiencies.
Add fields to .description is problematic. Applications tend
to use tuple unpacking to access the tuples in that list and
adding fields would break this.
In general, using tuples for things can may be extended in
the future is a bad idea. For DB API 3.0 we should probably
switch to a list of ColumnDescription objects instead.
Professional Python Services directly from the Source (#1, Jan 06 2004)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
More information about the DB-SIG