Confusion over Python drivers
in [PgSql]
|
From: Josh Berkus on 5 Feb 2010 19:42 > Imho a big problem is that it does way too much itself - i.e. it does not use > things like PQExecParams but does escaping/parsing itself... > Other people may think thats a good idea - I definitely do not think so. It also has issues with transaction control which cause idle transactions if the Django front-end times out due to load. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 5 Feb 2010 09:43 On fre, 2010-02-05 at 09:19 -0500, Bruce Momjian wrote: > While I realize experienced people can easily navigate this confusion, > I > am concerned about new Postgres adopters being very confused by this > and > it is hurting our database adoption in general. > > What is really needed is for someone to take charge of one of these > projects and make a best-of-breed Python driver that can gain general > acceptance as our preferred driver. I feel Python is too important a > language to be left in this state. The situation is unfortunate, but you might as well argue that too many Linux desktops or Linux distributions confuse new users and hurt adoption. These alternatives all exist for a reason, and it will be difficult to get some of them to abandon their work with the aim of reducing the overall "confusion". -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Smith on 6 Feb 2010 17:38 Marko Kreen wrote: > The pg8000 / bpgsql seem to be toy projects, and anyway you dont > want to use pure-Python drivers in high-performance environments. > We are not talking about C#/java here. > Right, and the comments from James reinforce this general idea: there is little value to the people who most want Python+PostgreSQL support in working on any of the pure Python implementations, because best case performance is still half or less of the ones that more directly wrap libpq. Even the best case with psycopg is enough of a performance hit as it is. > py-postgresql seems to be more serious, but as it's python3 only > which makes it irrelevant today. > Also true. > Psycopg was the leader, especially in web-environments, > but it has non-obvious license and with dead website it does not > seem that attractive. Although it is well-maintained still. > Best path forward would be to talk with Psycopg guys about > license clarification/change. > Agreed. A relicensed Psycopg, with a more professional looking introduction/documentation page (like the budding page on our Wiki) than what the initd web site has, seems like the best platform to hack on top of to me as well. The fact that they've moved to git recently makes it that much easier for another branch to exist even outside of their somewhat troubled infrastructure. To summarize what I saw on this thread, the primary wishlist of changes to it are: -License change -Consider refactoring to better follow standard driver practices, such as using PQExecParams -Improvement in transaction control to resolve issues that cause idle transactions -Possible simplifications in how it's implemented async operations, to improve robustness/reduce code complexity -Confirm/add multi-threaded support -Confirm/add support for the most common standard types (such as array) > PyGreSQL is the oldest, older than DB-API, and so it's DB-API > interface seems an afterthought and is untested/underused - eg. > it does not support bytea. > And if Psycopg can't be relicensed happily and/or improved as above, as the only other native Python driver PyGreSQL looks like the next candidate to build on top of. Its major issues are: -Test/complete/refactor for full DB-API 2.0 support -Add bytea support -Add extension support, perhaps modeled on what Psycopg. -Build a COPY extension -Confirm/add multi-threaded support -Confirm/add support for the most common standard types (such as array) Any other suggestions before I turn the above into a roadmap page on the wiki? -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 6 Feb 2010 18:55 Greg Smith wrote: > To summarize what I saw on this thread, the primary wishlist of changes > to it are: > > -License change > -Consider refactoring to better follow standard driver practices, such > as using PQExecParams > -Improvement in transaction control to resolve issues that cause idle > transactions > -Possible simplifications in how it's implemented async operations, to > improve robustness/reduce code complexity > -Confirm/add multi-threaded support > -Confirm/add support for the most common standard types (such as array) > > > PyGreSQL is the oldest, older than DB-API, and so it's DB-API > > interface seems an afterthought and is untested/underused - eg. > > it does not support bytea. > > > And if Psycopg can't be relicensed happily and/or improved as above, as > the only other native Python driver PyGreSQL looks like the next > candidate to build on top of. Its major issues are: > > -Test/complete/refactor for full DB-API 2.0 support > -Add bytea support > -Add extension support, perhaps modeled on what Psycopg. > -Build a COPY extension > -Confirm/add multi-threaded support > -Confirm/add support for the most common standard types (such as array) > > Any other suggestions before I turn the above into a roadmap page on the > wiki? Great summary! This is what I was hoping for. One suggestion on the license issue is that the LGPL seems like the type of license intended by the author, and I think it is an acceptable license to most client application programmers. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Kreen on 6 Feb 2010 19:48
On 2/7/10, Greg Smith <greg(a)2ndquadrant.com> wrote: > Marko Kreen wrote: > > Psycopg was the leader, especially in web-environments, > > but it has non-obvious license and with dead website it does not > > seem that attractive. Although it is well-maintained still. > > Best path forward would be to talk with Psycopg guys about > > license clarification/change. > > Agreed. A relicensed Psycopg, with a more professional looking > introduction/documentation page (like the budding page on our Wiki) than > what the initd web site has, seems like the best platform to hack on top of > to me as well. The fact that they've moved to git recently makes it that > much easier for another branch to exist even outside of their somewhat > troubled infrastructure. > > To summarize what I saw on this thread, the primary wishlist of changes to > it are: > > -License change Note that as long they use non-BSD licence, they need the exception for the horror that is the OpenSSL licence. So you cannot 100% satisfy the one-click-lawyers. > -Consider refactoring to better follow standard driver practices, such as > using PQExecParams This is long-term todo item for psycopg, seems offtopic to the "driver situation". > -Improvement in transaction control to resolve issues that cause idle > transactions This is routine bug in either app or psycopg, we have no reason to touch it. The guy should report to appropriate lists. > -Possible simplifications in how it's implemented async operations, to > improve robustness/reduce code complexity Long-term todo item for psycopg2, offtopic for "driver situation". > -Confirm/add multi-threaded support. Seems psycopg2 already has good enough threading. > -Confirm/add support for the most common standard types (such as array) psycopg2 has array support, I'd like to have tuple/record also. Minor todo item for psycopg, mostly but not completely offtopic for "driver situation". > > PyGreSQL is the oldest, older than DB-API, and so it's DB-API > > interface seems an afterthought and is untested/underused - eg. > > it does not support bytea. > > > > > And if Psycopg can't be relicensed happily and/or improved as above, as the > only other native Python driver PyGreSQL looks like the next candidate to > build on top of. Its major issues are: > > -Test/complete/refactor for full DB-API 2.0 support > -Add bytea support timestamp/timestamptz also... > -Add extension support, perhaps modeled on what Psycopg. > -Build a COPY extension They seems to have the low-level parts, just they are missing from DB-API interface. > -Confirm/add multi-threaded support > -Confirm/add support for the most common standard types (such as array) > > Any other suggestions before I turn the above into a roadmap page on the > wiki? I think we should concentrate on the PR problem and technical issues related to that, keep the other low-level and non-user-visible issues out. Or at least separate. (PsycopgTodo wiki page?) -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |