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.
> 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?
Both. The datestyle is set up in postgres.conf and you can change it
during a connection. You can even execute a query, retrieve a few rows,
then change the datestyle, then retrieve some other rows etc. That makes
the whole thing so problematic.
> 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).
I already thought about that, but do we really want the interface to
intercept such commands and interfere with them? It somehow does not
feel right. By the way, the user would still see the effect of changing
the datestyle when he casts dates to strings via SQL.
> 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.
As I suggested we could make it a settable attribute of the connection,
as it is realized in mx.ODBC.
>> 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?
Actually, what I meant is that the "type code" in cursor.description
must compare equal not only to DATE, but also to DATETIME, since DATE is
not defined in the DB-API 2 specs, and according to the specs, the type
code must match one of the predefined type objects.
> 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'm also European ;-) But "US" ("MDY") is the default subvariant in
PostgreSQL. If you set datestyle = "SQL", then it will be actually "SQL,
MDY". So it makes sense to assume datestyle is MDY. Anyway, "ISO" is the
default datestyle variant and has no "MDY" subvariant, the same is true
for the "German" datestyle. The MDY problem does only affect the "SQL"
and "POSTGRES" datestyles variants.
Maybe we can add another connection attribute that can be set to MDY or
DMY and will be initialized by looking at datestyle. If you use "set
datestyle", to change this ordering, you will also need to change that
attribute. (Intercepting all variants of "set datestyle" commands does
not feel right, see above).
--- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
