Hi Christoph,
you really have been working on my suggestions! thanks. I know, some
of the code was quite, how did you say, adventurous?, I agree... there
were reasons for writing it like that, but the main one was some sort of
joke about avoiding using the 'if'.
I will clean them.
On 2006-0730 18:32:45, Christoph Zwerschke wrote:
> I think mx.datetime should be supported, since datetime was only
> introduced in Python 2.3, not 2.1.
>
> 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
right, I had not checked. agreed.
mx.DateTime: default,
datetime: supported (and default if no mx.DateTime is found),
string conversion: backwards compatibility.
> For instance, the connect() function of the pgdb module could
> take an additional parameter "datetypes" which could be set to
> None = "str", "datetime" or "mx" = "mx.datetime". If datetime
> or mx datetypes are requested, then connect() could execute a
> "show datestyle" and check if the database is really running
> with ISO datestyle and raise an error otherwise. How do you
> think about that?
what about passing the whole module as a parameter? or a string
describing the format if a string is to be returned. if no parameter
is passed, stay on the preferred type, which, according to the db-api2,
is mx.DateTime (or datetime if no mx.DateTime is installed) (or string -
whatever the database says - if no mx.DateTime is installed and datatime
is not available)
again one thing I did not understand (among others, I mean): the database
runs with a specific datestyle or can you ask the connection to behave
according to a specific datestyle? in the first case, I would do a
"show datestyle" on connect. in the second, I would separate the cases:
if the user wants me to convert date/timestamps/intervals to string or
to something else than string. if string is the choice, then allow the
user to set the datestyle with the connection, to whatever he wants and
whenever he wants. if mx.DateTime or datetime module is to be used,
then do a "set datestyle" to set it to ISO at connect time and reject
all subsequent user 'set datestyle' commands, as they would break
the conversion or at least make the work more complicated (uselessly
complicated, since the user anyways does not see the effect of changing
the datestyle in the connection).
one more thing, I would like an extra function for setting the same
parameter if none was specified on connection. I can live without it,
but I would like it anyways.
On 2006-0731 02:01:11, Christoph Zwerschke wrote:
> Postgres | stdlib type | mx type | type object
> ----------+-------------+-----------+------------
> date | date | DateTime | DATE
> time | time | TimeDelta | TIME
> timestamp | datetime | DateTime | DATETIME
> interval | timedelta | TimeDelta | TIMEDELTA
ok.
it's really a pity that mx does not distinguish dates and timestamps.
> Type objects of DATE type will also compare equal to DATETIME.
also if the user is using the datetime module?
wouldn't that be confusing?
> 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?
well, I'm european, I would support 'SQL, European', I see no reason to
prefer 'SQL, US' instead. and anyways, Month, Day, Year seems to me
an even more pathological ordering than the german way of counting -
nineteen hundred seven and sixty... I can understand Day, Month, Year,
I prefer Year, Month, Day (hour, minute, second...)
but as I already wrote, I would prefer staying on ISO and allow other
formats only if the user is willing to use them directly.
I'll look into the cvs code and see what I can do with your comments,
it won't be too soon. :/
ciao,
Mario
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
