Hello Mario, thanks for the feedback. We may consider some of this in version 3.9.
pgdb returns DATETIME data as strings. in the case switch for DATETIME pgdb does not make any attempt to convert it from the representing string into a DateTime object. the result returned in fetch(one/all) does not hold any information about the original type in the database (indistinguishable from STRING).
I think the main problem here is that - as you already noticed - the date/time format can vary in PostGreSQL, depending on how you set datestyle. For instance, I have usually set datestyle=German, so your patch would not work. And datestyle can probably even altered during one session. I'm currently not sure how to get a universally valid solution.
Maybe somebody will come up with a good idea. One possibility would be to add a PyGreSQL configuration parameter that tells PyGreSQL if and how DateTimes should be treated, and it is in the responsibility of the application to set it appropriately.
Also, if we really want to return the type, then we should not only support absolute times, but also time delta types, and we should properly handle time zones and fractions of seconds in timestamps (your patch rounds all datetime types to seconds).
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. Unicode strings are automatically encoded to UTF-8 (actually, I think this is also not quite correct, since the server could have been configure with a different encoding).
You also write that the website is sometimes down and thus PyGreSQL not available. I did not experience this in the past, but a solution would be to put PyGreSQL in the cheese shop (PyPI) as well. D'Arcy, what do you think about that?
-- Christoph _______________________________________________ PyGreSQL mailing list [email protected] http://mailman.vex.net/mailman/listinfo/pygresql
