Re: [HACKERS] Confusion over Python drivers

2010-02-15 Thread Jeff Davis
On Sun, 2010-02-14 at 20:43 +0100, Florian Weimer wrote: The downside is that passing strings up to the application may have distinctly worse performance characteristics than passing a number. Yes, that is a good point. I tried to clarify this in the doc. I think this would fall under the

Re: [HACKERS] Confusion over Python drivers

2010-02-14 Thread Florian Weimer
* Jeff Davis: Agreed. Ultimately, the conversion has to be done somewhere, but I don't believe the driver is the place for it. Type conversions are always going to be imperfect, and this has some important consequences: * The type conversion system will be endlessly tweaked to improve it *

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-13 Thread Greg Smith
Jeff Davis wrote: Keep in mind that backwards compatibility is not the only issue here; forwards compatibility matters as well*. A lot of the encoding issues I wrote up ( http://wiki.postgresql.org/wiki/Driver_development ) will probably be real bugs in a python3 application using a driver that

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-12 Thread Federico Di Gregorio
On 12/02/2010 01:00, Jeff Davis wrote: * I tried installing psycopg2-2.0.13 and the build system apparently doesn't support python3.1, so I assume that psycopg2 doesn't support python3 at all. python3 was almost completely supported some months ago but then I had to fix some bugs and almost

Re: [HACKERS] Confusion over Python drivers

2010-02-12 Thread Tom Lane
Andrew McNamara andr...@object-craft.com.au writes: The solution is to write the query in an unambiguous way: SELECT $1::date + 1; You are missing the point: this is not about what types the SQL execution sees. It is about making sure the correct recv function is applied to the binary

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-12 Thread Jeff Davis
On Fri, 2010-02-12 at 10:38 +0100, Federico Di Gregorio wrote: On 12/02/2010 01:00, Jeff Davis wrote: * I tried installing psycopg2-2.0.13 and the build system apparently doesn't support python3.1, so I assume that psycopg2 doesn't support python3 at all. python3 was almost completely

Re: [HACKERS] Confusion over Python drivers

2010-02-12 Thread Andrew McNamara
Andrew McNamara andr...@object-craft.com.au writes: The solution is to write the query in an unambiguous way: SELECT $1::date + 1; You are missing the point: this is not about what types the SQL execution sees. It is about making sure the correct recv function is applied to the binary

Re: [HACKERS] Confusion over Python drivers

2010-02-11 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 The solution is to write the query in an unambiguous way: SELECT $1::date + 1; which is good practice, anyway. If it's not obvious to the type inference system, it's probably not obvious to you, and will probably surprise you ;) That

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-11 Thread Jeff Davis
On Wed, 2010-02-10 at 23:13 -0500, Greg Smith wrote: Until then, working apps have to be the primary motivation for what to work on here, unless there's a really terrible problem with the driver. The existing psycopg license and the web site issues were in combination enough to reach that

Re: [HACKERS] Confusion over Python drivers

2010-02-11 Thread Andrew McNamara
The solution is to write the query in an unambiguous way: SELECT $1::date + 1; which is good practice, anyway. If it's not obvious to the type inference system, it's probably not obvious to you, and will probably surprise you ;) That address this specific case, but it's ugly and not general.

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-11 Thread Andrew McNamara
Obviously this is less urgent than having a driver that works now, but it's still important. I think we would attract some goodwill from the python community if we were helping them move to python3, rather than sitting around waiting 'til they've already moved and decided that they can't use

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Kevin Ar18
I hope people don't mind my asking about this on the list... as I hinted at before, I don't really follow the development of PostgreSQL, I was just interested in the Python driver project that I heard about. Anyways, as I understand it, the current goal is to use psycopg and get it changed to

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Tom Lane
Kevin Ar18 kevina...@hotmail.com writes: When I first heard about the endeavor, I thought the goal was to take one or several of the non-copyleft projects, which were rather unfocused, and work with those teams to produce a really good implementation for Python. However, as I understand it

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Kevin Ar18
Well, all else being equal we'd certainly prefer a library that was licensed more like the core Postgres database. However, we don't have infinite resources, and an LGPL license is not a showstopper (at least not to the people who seem to be willing to work on this problem). The

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Greg Smith
Kevin Ar18 wrote: Based on that, I guess my question is what would it have taken to have picked one of BSD/MIT projects and working with those people instead? In other words, what key things affected the decision for psycopg? What areas is it so far ahead in or that would have just been

Re: [HACKERS] Confusion over Python drivers

2010-02-10 Thread Andrew McNamara
That's just a matter of prioritizing the issues. Put the big ones at the top, the trivia at the bottom, [...] I'd like to see a requirement for the use of PQexecParams() over PQexec() - even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy. -- Andrew McNamara, Senior

Re: [HACKERS] Confusion over Python drivers

2010-02-10 Thread Tom Lane
Andrew McNamara andr...@object-craft.com.au writes: That's just a matter of prioritizing the issues. Put the big ones at the top, the trivia at the bottom, [...] I'd like to see a requirement for the use of PQexecParams() over PQexec() - even when using libpq's PQescapeStringConn(),

Re: [HACKERS] Confusion over Python drivers {license}

2010-02-10 Thread Greg Smith
Tom Lane wrote: If you feel that a BSD/MIT license is a must-have for your purposes, you're certainly free to push development of one of the other driver projects instead, and to try to organize some other people to help. I don't believe anyone is trying to funnel all development effort into

Re: [HACKERS] Confusion over Python drivers

2010-02-10 Thread Andrew McNamara
I'd like to see a requirement for the use of PQexecParams() over PQexec() - even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy. Such a rule seems pretty entirely pointless, unless you have a way to enforce that the query string passed to the function hasn't been assembled

Re: [HACKERS] Confusion over Python drivers

2010-02-09 Thread Chris Browne
kevina...@hotmail.com (Kevin Ar18) writes: Of course all of this is from the perspective of Python users. Of course, you have your own features that you want from your end (from PostgreSQL's perspective). Perhaps this info would help you to know which avenue to pursue. No, those seem like

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Massa, Harald Armin
The pg8000 / bpgsql seem to be toy projects, and anyway you dont want to use pure-Python drivers in high-performance environments. I agree that there are some performance-challenges with pure-Python drivers. And we should not forget to look for the reasons for the incubation of that many

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Greg Smith
Massa, Harald Armin wrote: I agree that there are some performance-challenges with pure-Python drivers. And we should not forget to look for the reasons for the incubation of that many pure-Python drivers: a) Python is no longer one-language, one-implementation. There are (at least) cPython

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Gabriele Bartolini
Hi there, Greg Smith ha scritto: Looks like the first action item is to talk with the Psycopg people about their license. Oh: and I'm going to take care of this. License changes can be a very sensitive topic and I'm told that discussion probably needs to happy in Italian too; I can

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Massa, Harald Armin
Greg, The point isn't so much standardizing. Having a low performance Python driver turns into a PostgreSQL PR issue. I totally agree. And if you're writing a database driver with performance as a goal, native Python is simply not an option. yes. Additionally: performance is not the only

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 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 ... I would appreciate comments by anyone (Greg Sabino Mullane: I included you in

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Florian Weimer
* 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

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Florian Weimer
* Andrew McNamara: Any other suggestions before I turn the above into a roadmap page on the wiki? 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

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Jeff Davis
On Mon, 2010-02-08 at 20:29 +0100, Florian Weimer wrote: 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

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Andrew McNamara
http://code.google.com/p/ocpgdb/ I saw your note that you have to specify the types for date values etc. Is this really desirable or even necessary? Can't you specify the type as unknown (OID 705, I believe)? At work, we recently used to typelessness of Perl's DBD::Pg with great effect,

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Jeff Davis
On Tue, 2010-02-09 at 09:15 +1100, Andrew McNamara wrote: I can't see how this would work with binary query parameters - the server will see a blob of binary data and have no way to know what it represents. Unknown is unknown, whether in binary or text format. As far as I know, PostgreSQL never

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Andrew McNamara
On Tue, 2010-02-09 at 09:15 +1100, Andrew McNamara wrote: I can't see how this would work with binary query parameters - the server will see a blob of binary data and have no way to know what it represents. Unknown is unknown, whether in binary or text format. As far as I know, PostgreSQL never

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Jeff Davis
On Mon, 2010-02-08 at 09:14 +0100, Massa, Harald Armin wrote: And we should not forget to look for the reasons for the incubation of that many pure-Python drivers: All very good points. That's why the doc I wrote: http://wiki.postgresql.org/wiki/Driver_development is specifically targeted at

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Jeff Davis
On Tue, 2010-02-09 at 10:46 +1100, Andrew McNamara wrote: The problem is deeper than that - when query parameters use the binary option, the server has no way to decode the binary parameter without an appropriate type OID. Postgres does not attempt to decode anything (text or binary format)

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Andrew McNamara
On Tue, 2010-02-09 at 10:46 +1100, Andrew McNamara wrote: The problem is deeper than that - when query parameters use the binary option, the server has no way to decode the binary parameter without an appropriate type OID. Postgres does not attempt to decode anything (text or binary format)

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Jeff Davis
On Tue, 2010-02-09 at 12:51 +1100, Andrew McNamara wrote: Now, with the text format parameters, the parser usually does the right thing, since text formats have plenty of hints for us humans. The parser doesn't care whether it's text format or binary format when determining the type. However,

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Andrew McNamara
For a given type, the input function may be more likely to catch an input error than the recv function; or the reverse. Either way, it is very type-specific, and the only difference is the whether the input is misinterpreted (type error not caught; bad) or an error is thrown (type error caught;

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Jeff Davis
On Tue, 2010-02-09 at 13:56 +1100, Andrew McNamara wrote: For a given type, the input function may be more likely to catch an input error than the recv function; or the reverse. Either way, it is very type-specific, and the only difference is the whether the input is misinterpreted (type error

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Jeff Davis
On Mon, 2010-02-08 at 20:50 +0100, Florian Weimer wrote: I saw your note that you have to specify the types for date values etc. Is this really desirable or even necessary? Can't you specify the type as unknown (OID 705, I believe)? I believe the problem that Andrew is describing is that:

Re: [HACKERS] Confusion over Python drivers

2010-02-08 Thread Andrew McNamara
If the date is passed in binary format, it will pass it to int4recv() -- but because the date is 4 bytes, and int4recv is defined for any 4-byte input, it won't cause an error; it will produce a wrong result. In other words, the binary representation for a date _is_ a valid binary representation

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Greg Smith
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,

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Marko Kreen
On 2/7/10, Robert Haas robertmh...@gmail.com wrote: On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen mark...@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

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Massa, Harald Armin
Marko, 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. Those lack of non-essential cool features is right on topic - because

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Josh Berkus
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

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Greg Smith
Greg Smith wrote: 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. Oh: and I'm going to take

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Greg Smith
Josh Berkus wrote: 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. I'm going

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Andrew McNamara
Any other suggestions before I turn the above into a roadmap page on the wiki? 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:

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Greg Smith
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

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Andrew McNamara
I added you into the list at http://wiki.postgresql.org/wiki/Python Thanks. Can you check what I put in there, confirm Windows compatibility, and comment on Python 3.X support? I haven't tried it under Windows and I haven't had any feedback either way from Windows users. For now, ocpgdb has

Re: [HACKERS] Confusion over Python drivers

2010-02-07 Thread Jeff Davis
On Mon, 2010-02-08 at 12:25 +1100, Andrew McNamara wrote: For now, ocpgdb has no Python 3 support (I don't foresee any real problems, however). Encoding issues are the big one. There are a couple gotchas, and I provided the details here:

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Jeff Davis
On Fri, 2010-02-05 at 10:35 -0800, Josh Berkus wrote: I'm not as concerned about confusion as the fact that *all* of the various Python drivers suck in different, and crippling, ways. I don't care how many drivers we have, as long as we have at least one 1st-class driver. Absolutely. And I

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Greg Smith
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

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Bruce Momjian
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

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Marko Kreen
On 2/7/10, Greg Smith g...@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

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Josh Berkus
Finally, I just don't see the existing (often PG specific) goals that I have in mind for it appealing to the majority of [web framework/abstraction] users. What are those goals? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Robert Haas
On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen mark...@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

[HACKERS] Confusion over Python drivers

2010-02-06 Thread Kevin Ar18
I saw this on reddit and thought I might drop a line. I went through this same issue, trying to find a postgresql driver. Mostly, I had no intention of using psycopg because of its copyleft licensing. (Of course, I don't need to go into why.) Anyways, here's some info that might help on

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Josh Berkus
Kevin, Of course all of this is from the perspective of Python users. Of course, you have your own features that you want from your end (from PostgreSQL's perspective). Perhaps this info would help you to know which avenue to pursue. That's invaluable. Thanks for chiming in! --Josh

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread James William Pye
On Feb 6, 2010, at 5:51 PM, Josh Berkus wrote: Finally, I just don't see the existing (often PG specific) goals that I have in mind for it appealing to the majority of [web framework/abstraction] users. What are those goals? I think the most interesting one that has yet to be implemented

Re: [HACKERS] Confusion over Python drivers

2010-02-06 Thread Jeff Davis
On Fri, 2010-02-05 at 09:19 -0500, Bruce Momjian wrote: My son has brought to my attention that our current crop of Python client libraries is inadequate/confusing. I took a look myself, and asked on our IRC channel, and am now convinced this area needs attention. I have written up a set of

[HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
My son has brought to my attention that our current crop of Python client libraries is inadequate/confusing. I took a look myself, and asked on our IRC channel, and am now convinced this area needs attention. First, the sheer number of libraries is confusing. This is the page from the Postgres

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Massa, Harald Armin
Bruce, http://wiki.postgresql.org/wiki/Python The first one listed, Psycopg, is noted as preferred libpq-based driver, but the license is GPL. Isn't that a problem for many client applications? The licence of psycopg2 is a little more complicated; the GPL in that summary just tries

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
Massa, Harald Armin wrote: Bruce, http://wiki.postgresql.org/wiki/Python The first one listed, Psycopg, is noted as preferred libpq-based driver, but the license is GPL. Isn't that a problem for many client applications? The licence of psycopg2 is a little more complicated;

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Peter Eisentraut
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

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Tim Bunce
On Fri, Feb 05, 2010 at 09:19:26AM -0500, Bruce Momjian wrote: My son has brought to my attention that our current crop of Python client libraries is inadequate/confusing. I took a look myself, and asked on our IRC channel, and am now convinced this area needs attention.

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
Peter Eisentraut wrote: 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

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
Tim Bunce wrote: On Fri, Feb 05, 2010 at 09:19:26AM -0500, Bruce Momjian wrote: My son has brought to my attention that our current crop of Python client libraries is inadequate/confusing. I took a look myself, and asked on our IRC channel, and am now convinced this area needs attention.

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Peter Eisentraut
On fre, 2010-02-05 at 14:45 +, Tim Bunce wrote: Does Perl have a similar mess? I don't think so. The primary database interface is DBI and as far as I can see there's only one DBI PostgreSQL driver: http://search.cpan.org/dist/DBD-Pg/ I think another difference is that the Perl DBI

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
Peter Eisentraut wrote: On fre, 2010-02-05 at 14:45 +, Tim Bunce wrote: Does Perl have a similar mess? I don't think so. The primary database interface is DBI and as far as I can see there's only one DBI PostgreSQL driver: http://search.cpan.org/dist/DBD-Pg/ I think another

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Josh Berkus
I think another difference is that the Perl DBI interface is very rich, whereas the Python DB-API is quite minimal and almost forces people to write (incompatible) extensions. The DB-SIG at Python that ought to drive all this is also quite dead, possibly because everyone has moved on to

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Josh Berkus
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

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
Josh Berkus wrote: 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

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
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.

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Greg Smith
Bruce Momjian wrote: While I realize experienced people can easily navigate this confusion... No, that's the worst part--the more you know and the deeper you dig into it, the more broken you realize the whole thing is. When one of the best drivers (in some respects) has a web page that

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Bruce Momjian
Greg Smith wrote: Bruce Momjian wrote: While I realize experienced people can easily navigate this confusion... No, that's the worst part--the more you know and the deeper you dig into it, the more broken you realize the whole thing is. When one of the best drivers (in some respects)

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Jeff Davis
On Fri, 2010-02-05 at 09:38 -0500, Bruce Momjian wrote: Wow, that is super-confusing. Agreed. Standardization among licenses is useful, and I think it's important to have a driver with a license that people already understand. Regards, Jeff Davis -- Sent via pgsql-hackers mailing

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Marko Kreen
On 2/5/10, Josh Berkus j...@agliodbs.com wrote: I think another difference is that the Perl DBI interface is very rich, whereas the Python DB-API is quite minimal and almost forces people to write (incompatible) extensions. The DB-SIG at Python that ought to drive all this is also

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Josh Berkus
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

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Andres Freund
On Friday 05 February 2010 21:34:53 Marko Kreen wrote: On 2/5/10, Josh Berkus j...@agliodbs.com wrote: I think another difference is that the Perl DBI interface is very rich, whereas the Python DB-API is quite minimal and almost forces people to write (incompatible) extensions. The

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread Marko Kreen
On 2/5/10, Greg Smith g...@2ndquadrant.com wrote: The issues here have already been identified: the Perl DBI is an excellent spec, while the Python one is so weak everybody ends up needing their own extensions to it. And then portability *even among Python PostgreSQL drivers* goes out the

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread James William Pye
On Feb 5, 2010, at 1:34 PM, Marko Kreen wrote: py-postgresql seems to be more serious, but as it's python3 only which makes it irrelevant today. Furthermore, if it did work on python2, it's *not* something that's going to appeal to mainstream users (Python heavy web frameworks) as it

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread James William Pye
On Feb 5, 2010, at 11:34 AM, Josh Berkus wrote: For people who use Python a lot, could I have a list of the deficiencies in DBAPI? I've got my horse and lance ready. Given that SQLAlchemy isn't for everyone, of course ... it couldn't be, or Django would use it, no? Here are some to start

Re: [HACKERS] Confusion over Python drivers

2010-02-05 Thread James William Pye
On Feb 5, 2010, at 8:00 AM, Peter Eisentraut wrote: I think another difference is that the Perl DBI interface is very rich, whereas the Python DB-API is quite minimal and almost forces people to write (incompatible) extensions. Yep. The DB-SIG at Python that ought to drive all this is also