[DB-SIG] WHat's the status of DB modules and datetime.py supp ort?
Federico Di Gregorio
fog at initd.org
Fri Jan 2 10:29:39 EST 2004
Il ven, 2004-01-02 alle 16:00, Kevin Jacobs ha scritto:
> This is easy when all data come from the DB-API driver and are passed back
> to that driver, though things become much more invasive when data come from
> user interfaces, or other sources that do not have the magic type
agreed. but adding the magic type information is not a task for the
database driver, imho. your example of data coming froma gui just
reinforce my idea of a protocols-driver layer over the DBAPI and under
the OR mappers or applications.
> You miss the point. Your literal round-tripping proposal does not address
> the needs of those with data elements that may have _multiple_ literal
> forms. i.e., the type is not enough to specify the literal encoding when
> used as a bound variable.
do such types exists? really, i can't imagine a (postgresql) data type
that can't do the round trip.
> Put simply: I want the simplest, most primitive, most light-weight types
> returned in rows. This way I can apply my own type mapping layer without
> sacrificing efficiency for any superfluous and/or flawed functionality.
ok. i am currently rewriting (finishing, that is) psycopg's type system.
can you please tell me _exactly_ how your ideal type-system should work?
i will be glad to give it a try if it is clearly better than current
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer fog at debian.org
INIT.D Developer fog at initd.org
One key. One input. One enter. All right. -- An american consultant
(then the system crashed and took down the *entire* network)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://mail.python.org/pipermail/db-sig/attachments/20040102/0acfa579/attachment-0001.bin
More information about the DB-SIG