psycopg2-2.0.6b2 does not allow lists in cursor.execute

[mde@…]

The latest version of Django (currently 0.96) does not work with the latest release of psycopg2 (currently psycopg2-2.0.6b2). Doing "python manage.py syncdb" fails with a ProgrammingError that says "argument formats can't be mixed."

Django 0.96/Postgres works fine if you go back to psycopg2-2.0.5.1.

It would save people frustration if the installation docs mentioned that Django depends on a specific version of a DB connector.

[Malcolm Tredinnick]

Django doesn't (intend) to depend on a specific version of any compatible database backend and we've never indicated that is the way we work. Perhaps the cause of the problem is because you're using a beta release and we haven't tested against changes that may have crept in there?

2.0.6b2 is a beta release, it's not a final release (2.0.5.1 is the latest final release they've done). Expecting a few transitional problems in a non-final would be par for the course. Thanks for testing it and pointing these out.

I've grabbed the latest code and will have a play around at some point to see if the problem is on our end or due to an unfortunate change in psycopg2.

[pigletto@…]

I've found same problem and submitted this to psycopg collector.
There is an answer from them. Take a look: ​http://initd.org/tracker/psycopg/ticket/178#comment:1

[Malcolm Tredinnick]

What a shame. That's a bad design choice on psycopg's part. There is no good technical reason to allow tuples and not lists in that cursor.execute() --- any sequence-like object should work.

We're going to have to work around their choice then. Fortunately, it shouldn't be too hard. Changing title to reflect the real problem.

[deaston]

I don't really understand this, considering the documentations recommends using lists. Check out the second to last Q/A here:

​http://www.initd.org/tracker/psycopg/wiki/PsycopgTwoFaq

Am I misunderstanding? Seems like there could potentially be many projects that depend on the use of lists in cursor.execute().

To make things work temporarily I just commented out two blocks of code in cursor_type.c that test for "kind" and rebuilt. Probably not the best idea but seems to work for my purposes (just playing/experimenting).

[pd@…]

As of now, the problem is still here with the current SVN release of Django and psycopg2_2.0.6~b2. Is there any solution in sight? I'd really like to use Django with PostgreSQL.

[anonymous]

Please don't post "when will this be done" comments. They don't contribute anything. If you want it done faster, post a patch and we'll review it. Otherwise, stop trying to use the beta release and use the latest final release of psycopg2, which works fine with Django.

@deaston: comments like that are better sent the the psycopg2 developers. They aren't anything we can control. We'll have to eventually adjust Django to handle their design decisions.

[Malcolm Tredinnick]

(previous comment by me.)

[Jonas von Poser]

It has been solved it in the stable version. So update it:

$ POSTGRES_INCLUDE=/usr/include/postgresql sudo easy_install -U psycopg2

[rollacosta]

I am using with psycopg2 v2.0.6 with the bleeding-edge Django from SVN. syncdb fails with:

Traceback (most recent call last):

File "manage.py", line 11, in <module>

execute_manager(settings)

File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1742, in execute_manager

execute_from_command_line(action_mapping, argv)

File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1639, in execute_from_command_line

action_mapping[action](int(options.verbosity), options.interactive)

File "/usr/lib/python2.5/site-packages/django/core/management.py", line 538, in syncdb

cursor = connection.cursor()

File "/usr/lib/python2.5/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 58, in cursor

cursor.execute("SET TIME ZONE %s", [settings.TIME_ZONE])

psycopg2.ProgrammingError: unrecognized time zone name: "America/Chicago"

[Malcolm Tredinnick]

The previous comment's error is unrelated to this ticket. The error reported is typical for when there was an earlier SQL problem and you continue to try and use the database without rolling back the transaction. It is expected and correct behaviour.

Perhaps you might want to supply some details of what you are trying to do to the django-users mailing list if you cannot work out the problem.

[rollacosta]

On closer inspection, turned out to be a bungle up with Postgres on Ubuntu Gutsy. Using bleed-edge there too...
More here --> ​https://code.launchpad.net/ubuntu/gutsy/+source/postgresql-8.2/8.2.4-2
Conclusion: Too much bleeding edge stuff is bad!

[anonymous]

Two bugs are actually reported here.

To fix second bug (about unrecognized time zone name: "America/Chicago" or "GMT" or any other) you should get directory /usr/share/postgresql/8.2/timezone somewhere, as it is empty (from rollacosts's link: debian/postgresql-8.2.install: Actually install the "timezone" symlink, not the dereferenced files.)

I just made symlink to /usr/share/postgresql/8.1/timezone.

[anonymous]

Two bugs are actually reported here.

To fix second bug (about unrecognized time zone name: "America/Chicago" or "GMT" or any other) you should get directory /usr/share/postgresql/8.2/timezone somewhere, as it is empty (from rollacosts's link: debian/postgresql-8.2.install: Actually install the "timezone" symlink, not the dereferenced files.)

I just made symlink to /usr/share/postgresql/8.1/timezone.