[PyGreSQL] DATETIME fields and DateTime objects in pgdb

[Christoph Zwerschke]

> 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