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 opt
* 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
d
>Andrew McNamara 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 parameter data.
>
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 compl
Andrew McNamara 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 parameter data.
Indeed,
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
>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 p
>>>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
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 th
-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 ;
>> 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
>asse
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
psyc
Andrew McNamara 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(), PQexec() makes me uneasy.
S
>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 Develo
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 too
> 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 attract
Kevin Ar18 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 (based on what
> Gre
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
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 lik
>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
>representati
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:
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 (typ
>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 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.
> Howeve
>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 fo
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 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 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,
>PostgreSQ
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 neve
>> 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
>e
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 lan
* 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
* 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 exi
-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
> y
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
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 arrange
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 (th
>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 pure-P
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:
http://wiki.postgresql.org/wiki/Driver_development#Text
>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 ha
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 int
>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:
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 to
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
>> 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 n
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 - b
On 2/7/10, Robert Haas wrote:
> On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen 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
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 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
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 imple
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 Be
On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen 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
> 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 sub
On 2/7/10, Greg Smith 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 gu
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
>
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 w
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.
A
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 a
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 st
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 *partial
On 2/5/10, Greg Smith 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 window.
Well, no.
On Friday 05 February 2010 21:34:53 Marko Kreen wrote:
> On 2/5/10, Josh Berkus 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
> 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 t
On 2/5/10, Josh Berkus 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 quite dead, p
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 lis
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 respec
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 looks
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/chan
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 wit
> 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 o
> 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
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
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
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
> > at
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.
>
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.
>
> http://
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 som
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 m
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 ju
80 matches
Mail list logo
