From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | psycopg(at)postgresql(dot)org |
Subject: | Issue with DateStyle and pgbouncer |
Date: | 2013-03-18 13:53:29 |
Message-ID: | CA+mi_8bM8vR=uDxjJ3KqYTA1BEbE4AVCu5YqObHSZ=L3VSwMdw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
Hello,
trawling on twitter and lurking on github I've intercepted some cries
of pain caused by psycopg+pgbouncer regarding DateStyle. psycopg only
works with ISO style dates: usually it knows the DateStyle on
connection [1] and changes it if the setting isn't compatible.
Unfortunately pgbouncer doesn't send the DateStyle setting on
connection, and psycopg conservatively sets DateStyle to ISO when the
information is missing: on pgbouncer this may mean an extra query
every query. Not amusing.
Because I'm going to release version 2.5 soon, so it's a good time to
break something. What I'd do is: if the DateStyle info is missing
(i.e. you are on pgbouncer or other "broken" middleware) just assume
the date style is correct. This would break dates adaptation for users
of a database with non-standard DateStyle (e.g. "German") running
through pgbouncer: for these users there is an easy fix: pass the
extra DateStyle=ISO option at connection, either in the connection
string:
psycopg2.connect("host=here user=that options='-c DateStyle=ISO' ")
or as an extra connection parameter:
psycopg2.connect(host="here" user="that" options="-c DateStyle=ISO")
or using an env variable:
$ export PGOPTIONS='-c DateStyle=ISO'
...
>>> psycopg2.connect(DSN) # unchanged
It's a one char change in the code and a quite tricky case to document...
Comments?
Thank you,
-- Daniele
[1] http://www.postgresql.org/docs/current/static/libpq-status.html#LIBPQ-PQPARAMETERSTATUS
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2013-03-18 19:15:53 | Re: Issue with DateStyle and pgbouncer |
Previous Message | Jan Wrobel | 2013-03-13 12:12:22 | Re: Is it allowed to reuse a connection on which another thread waits for notifications? |