[DB-SIG] Type code mappings: expanding the type objects

[Federico Di Gregorio]

Il lun, 2004-01-05 alle 18:48, M.-A. Lemburg ha scritto:
[snip]
> The bazar is open :-)

let's start with a _very_ small change, i.e., augmenting the number of
type objects. i think we can do that in an absolutely backward
compatible way. instead of having a flat set of type objects let's order
them by placing the old ones at the first level of a tree and the others
on the second level, as leaves:

STRING
|__CHAR
|__VARCHAR
|__TEXT
BINARY
NUMBER
|__INTEGER
|__LONGINTEGER
|__FLOAT
|__COMPLEX
DATETIME
|__TIME
|__DATE
|__TIMESTAMP
|__INTERVAL
ROWID

and require that is a type object matches a type code, the same type
code is matched by the parent(s) too. this allows for expanding the
types without requiring any modification of old code, because if, for
example, the type code for an int4 matches INTEGER it will always (as in
DBAPI-2.0) also match NUMBER.

the list is just preliminary and open to suggestions. i suppose we can
have more string types (unicode anyone?), different binaries, times with
tz information and such.

the trick here is to let the modules implement extra type objects (like
geometic types in postgresql) but mandate a wide enough base to satisfy
everybody.
 
-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog at debian.org
INIT.D Developer                                           fog at initd.org
   God is real. Unless declared integer. -- Anonymous FORTRAN programmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://mail.python.org/pipermail/db-sig/attachments/20040105/36f7c730/attachment.bin