let me understand the problem you see. if I say that a datestyle is
linked to a database connection, why do you state that the datestyle
could change *within* a session? wouldn't you consider such a change
as pathological?
An application might switch the datestyle depending on the prefered
language of the individual user. After the user switched the language,
the datestyle would be set differently. Of course, you could claim
setting a German datestyle is a pathological situation anyway ;-)
what about adding a setdatestyle method to the pgdbCnx connection object
and a __datestyle field to the pgdbTypeCache?
the value of the field would then be used by the pgdbTypeCache to
decide what to do with the DATETIME strings coming from the database.
and which way to convert DateTime objects directed to the database.
That would be possible, but only for applications which are aware of
that method and do not directly change the datestyle. You would have to
initialize __datestyle with the result of a "show datestyle" request.
yes, I'm quite aware of this. why not just start with this one? as you
see, I favour the wiki-like development style "I write, you complete,
he corrects". and I'm available to be any of the three persons! :)
Let's hear D'Arcy's opinion; he is actually the owner of the project. In
any case, we need to somehow maintain backward compatibility and if we
introduce something new we need a good concept. We might also check how
other PostGreSQL interfaces deal with that problem.
By the way, your patch changes a check for StringType to
StringTypes (i.e. including unicode). I think this has been
already changed in PyGreSQL since 3.6 or so.
are you sure? could you check? I am now looking at my diff for 3.8
and I still need it.
The change was made here:
http://www.druid.net:88/pubcvs/cvsweb.cgi/pygresql/module/pgdb.py.diff?r1=1.26;r2=1.27;f=h
At the point where types.StringType is checked, unicode has been already
encoded to an ordinary string.
-- Chris
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
