It may work if coded carefully around its bugs. The most egregious example I
found was that instead of
returning a tuple with the field values expected after doing
SELECT (field1, field2, field3) from table
it returns the STRING with those fields in it, for example
'(8,"just a second, dammit",9)'
that has to be unpacked programmatically. This happens in both psycopg and
psycopg2.
On Thu, Mar 31, 2011 at 12:39 PM, John DeRosa <[email protected]> wrote:
> That's the first time I've heard psycopg2 described that way. We use it at
> work (a large Django application), and I've used it for a couple (3? 5?)
> years. It's rock solid.
>
> On Mar 31, 2011, at 11:59, Mark McWiggins <[email protected]>
> wrote:
>
> > Hi All,
> >
> > I've just been working on a project to connect to a Postgresql database
> with Python, and I found:
> >
> > * SQLObject too slow
> > * SQLAlchemy too slow
> > * psycopg2 very buggy
> > * psycopg somewhat buggy
> >
> > Is the MySQL interface any better?
> >
> > --
> > Mark McWiggins
> > 425-369-8286 (cell)
>
>
--
Mark McWiggins
425-369-8286 (cell)
