Mario, here are some more considerations regarding the datetime patch:
The DB-API 2 specification says:
The *preferred* object types for the date/time objects
are those defined in the mxDateTime package.
Starting with Python 2.3, module authors can *also* use
the object types defined in the standard datetime module
The current implementation does it exactly like this.
Still, it would be nice to have an option for choosing between datetime,
mx.DateTime and raw (string) format for return values.
For the input values (sql parameters) it does not matter, since you have
to use the Date(), Time() and Timestamp() constructors provided by the
pgdb module anyway, you do not input mx.DateTime objects directly.
Another thing that needs to be changed in your patch:
You invented some type objects such as TIMEINTERVAL which are not part
of the DB-API specs. I think that is possible, but you must take care
that all type codes (returned in the cursor.description) do also equal
one of the type objects defined in the specs. Currently, this was also
wrong for MONEY which should compare equal to NUMBER.
I suggest the following names and assignments of type objects:
Postgres | stdlib type | mx type | type object
----------+-------------+-----------+------------
date | date | DateTime | DATE
time | time | TimeDelta | TIME
timestamp | datetime | DateTime | DATETIME
interval | timedelta | TimeDelta | TIMEDELTA
Type objects of DATE type will also compare equal to DATETIME.
I have already added these type objects in the CVS, and fixed the issue
with the MONEY type (these changes will do no harm). (For
simplification, I have omitted deprecated data types and timezone
variants above, but they are included in the module.)
I have also found an answer to the question "how to deal with datestyle
settings different from ISO". Actually, there are only 4 different
variants, and they can be distinguished from the date value (e.g. the
separator is different for German style). It should be a simple thing to
write a parser which can convert all these date styles correctly (or use
the parser in mx.DateTime if available). The only problem is that one of
the 4 datestyles ("SQL") has 2 subvariants ("US" and "European") which
cannot be distinguished by looking at the value only. I suggest we
assume "US" (default), so of the 5 different datestyles only "SQL,
European" will not be converted correctly. I think we can live with that
if it is clearly documented. How do you think about that?
-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
