Mario Frasca wrote:
>>> what about passing the whole module as a parameter?
>> I think a constant is better because it allows also other modes such as
>> returning dates as tuples.
>
> I'm not sure I see your point. mine was this:
>
> import datetime, mx.DateTime, pgdb
> ddb = pgdb.connect(user = ..., ..., datestyle = datetime)
> xdb = pgdb.connect(user = ..., ..., datestyle = mx.DateTime)
> sdb = pgdb.connect(user = ..., ..., datestyle = 'ISO')
I know. I was referring to the mx.odbc attribute "datetimeformat". I
think we should use the same attribute and the same values, instead of
inventing something new. That attribute can take the following values:
DATETIME_DATETIMEFORMAT [default]
DateTime and DateTimeDelta instances
TIMEVALUE_DATETIMEFORMAT
Ticks (numberof seconds since the epoch) and tocks (number of
seconds since midnight)
TUPLE_DATETIMEFORMAT
Python tuples (see the above table for definitions)
STRING_DATETIMEFORMAT
Python strings. The format used depends on the settings in the
database. See your database's manuals for the exact format and
ways to change it.
(see: http://www.egenix.com/files/python/mxODBC.html)
We only need to split DATETIME_DATETIMEFORMAT into two constants for
stdlib datetime and mx.DateTime.
> what do you mean, 'dates as tuples'? as long as that is not a subtype
> of datetime nor mx.DateTime, I don't see the problem. is there any?
As far as I understand, with TUPLE_DATETIMEFORMAT, mx.odbc will return
(year, month, day, ...) tuples. This may be useful in some cases.
> otherwise (without this example) I would say that it does not feel
> right to change the datestyle on which the library counts... all right,
> maybe not intercept the commands to reject them, but possibly to keep
> track of the current datestyle without the need to poll for it each time
> a date|datetime|timedelta value is retrieved.
> ...
> if we intercept 'set datestyle' commands to keep track of the current
> datestyle, this function would be unnecessary.
I'm not sure how well this works when you fetch rows in chunks with
fetchmany() and intersparsed 'set datestyle' commands, because there is
a row cache involved. (I know it's a pathological case, but if possible
we should do it "right".) In the worst case, for every row, you may need
to store the value of datestyle at the time when the row was retrieved.
Also, it is not trivial to intercept 'set datestyle' commands since
there are various syntax variants, like 'alter database set datastyle to
...' or 'set datestly = ...', there may be intersparsed comments or
whitespace, and uppercase/lowercase must be ignored, and there are many
synonyms for the possible values of datestyle, e.g. "us" = "noneuropean"
= "mdy", and combinations such as "sql, mdy". Also, there is a "reset
datestyle" command that resets to the value in postgres.conf. So I
really would avoid this interception if possible, because of the
complexity, and rather accept that in the two problematic subvariants,
you can only use the raw dateformat.
BTW, we still need to define whether mx.datetime or raw should be the
default date format. I would prefer mx.datetime, but then we are not
backward compatible.
> you know what? I think we have spoken enough and that it might be time
> to start coding something... I'm going further from the released 3.8
> version, or let me know where I can find a most recent cvs image...
>
> I will post my patches here, but you can also follow me on
> http://ibo.cvs.sourceforge.net/ibo/ibo3/python/PyGreSQL/?pathrev=latest_3_8
That's a good idea. When it is stable, I will go through it and
incorporate this functionality to PyGreSQL. Another thing: I suggest you
define functions for the date conversion (like str2date, str2time,
str2datetime, str2interval), and also write a unittest module for these
functions. (If you don't do it, I will do it anyway before incorporating
it into PyGreSQL).
-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
