Confusion over Python drivers
in [PgSql]
|
From: Greg Smith on 7 Feb 2010 05:18 Marko Kreen wrote: > 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?) > That's just a matter of prioritizing the issues. Put the big ones at the top, the trivia at the bottom, and if you knock stuff of there somewhere along the way you discover you've made enough progress that the PR stuff starts going away, because people are able to get their work done with less drama. Here's a full TODO page that includes everything mentioned here as best I could summarize it: http://wiki.postgresql.org/wiki/Python_PostgreSQL_Driver_TODO Looks like the first action item is to talk with the Psycopg people about their license. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com -- 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 7 Feb 2010 05:20 On 2/7/10, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen <markokr(a)gmail.com> wrote: > > This is long-term todo item for psycopg, seems offtopic > > to the "driver situation". > > [...] > > > This is routine bug in either app or psycopg, we have no reason > > to touch it. The guy should report to appropriate lists. > > [...] > > > Long-term todo item for psycopg2, offtopic for "driver situation". > > [...] > > > 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". > > > I'm not a Python user myself, but I have trouble understanding how you > can describe bugs in one of the Python drivers as off-topic to the > Python driver situation. I thought the topic was "Confusion over Python drivers"? The only bug there was likely app one, or at least its not widespread so off-topic. Rest are more like non-essential cool features, so again off-topic. -- 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
From: Florian Weimer on 8 Feb 2010 14:29 * Jeff Davis: > I have written up a set of guidelines for driver development based on > what I learned working on ruby-pg: > > http://wiki.postgresql.org/wiki/Driver_development Interesting, thanks. I'm contemplating to create a new language binding for libpq (or, to be more precise, turn an existing language binding into something that can be published). I've been agonizing a bit over how to create a bridge between the host language type system and the PostgreSQL type system. If I understand you correctly, you suggest to leave everything as strings. This solution has the appeal of being implemented easily. It also sidesteps a lot of issues revolving around different representation choices for numbers. Do you really suggest to preserve the PQexecParams API verbatim, that is, passing in three arrays containing type, value, and format? That seems to be a bit problematic. I suspect the common case will be to use unknown types, text format, and the default conversion from values to strings. Only for BYTEA values, something else is required, and I'm wondering how to encode that (the host language doesn't offer a distinction between text and binary strings). Conversely, for result sets, I'm tempted to transparently decode escaped BYTEA columns. > Note that the ruby-pg driver doesn't 100% adhere to those standards > (encoding is the primary problem, and that will be fixed). Lack of Unicode support means that I can punt that to application authors, I guess. By the way, the downside of using strings everywhere is that your binding API will most likely not work with SQLite (or any other SQL-like database which lacks column type information). -- 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: Josh Berkus on 7 Feb 2010 14:50 >> I'm not a Python user myself, but I have trouble understanding how you >> can describe bugs in one of the Python drivers as off-topic to the >> Python driver situation. > > I thought the topic was "Confusion over Python drivers"? > > The only bug there was likely app one, or at least its not widespread > so off-topic. Rest are more like non-essential cool features, > so again off-topic. Not at all, except that maybe this discussion belongs on -advocacy rather than here. Driver quality is partly performance and stability, but also partly what features it implements and how well it implements them. *particularly* for PostgreSQL, which is a database with lots of cool features; if the driver doesn't support our cool features, then they don't matter to Python developers. Anyway, I don't yet have a full diagnosis on the transaction control issue or I'd already have posted it to psycopg -- it may be a toxic interaction between Django and Psycopg2 rather than psycopg2 alone. I'd not have brought it up except for this discussion. --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: Greg Smith on 7 Feb 2010 19:19
Andrew McNamara wrote: > I got sick of the constant stream of escaping bugs impacting on psycopg > and pyPgSQL, and wrote my own DB-API driver, using the more modern > libpq/binary/protocol 3 APIs where ever possible. The result is BSD > licensed: > http://code.google.com/p/ocpgdb/ > I added you into the list at http://wiki.postgresql.org/wiki/Python Can you check what I put in there, confirm Windows compatibility, and comment on Python 3.X support? I'd be curious to hear more about the escaping bugs you ran into as well. We already have some notes on the TODO that pushing more of this work toward the standard libpq routines would seem appropriate for things passing between the driver and libpq. Were the issues you ran into on that side, or more on the Python side of how things were being formatted? -- 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 |