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
* 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
*
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
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
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
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
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
-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
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
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.
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
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
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
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
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
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
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(),
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
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
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
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
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
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
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
-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
* 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
* 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
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
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,
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
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
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
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)
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)
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,
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;
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
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:
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
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,
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
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
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
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
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
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:
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
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
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:
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
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
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
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
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
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
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
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
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
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
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;
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
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.
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
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.
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
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
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
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
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
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.
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
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)
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
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
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
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
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
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
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
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
80 matches
Mail list logo
