Confusion over Python drivers
in [PgSql]
|
From: "Massa, Harald Armin" on 7 Feb 2010 06:27 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 what one developer may see as "non-essential" is the most important feature for the next developer. Exactly these kind of issues are the source of the confusion we now phase: developer B needing feature X, which was ignored by driver A. So I concur to put them on the discussion agenda; if they drop out of priority, at least it is documented WHY and will save other developers these thoughts. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger StraÃe 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
From: Jeff Davis on 8 Feb 2010 19:01 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) until it figures out what type it is. > As you say, postgres will cast types depending on context, however this > is stricter when binary parameters are used (because they only have one > valid interpretation, whereas a text parameter may have several). Type casts are a different matter; they are only done after the unknown literals' types have been determined: create table n(i int); -- insert numeric literal, which is cast to int (assignment cast) insert into n values(5.0); -- succeeds -- insert unknown literal, which is inferred to be of type int insert into n values('5.0'); -- fails on integer type input function ERROR: invalid input syntax for integer: "5.0" LINE 1: insert into n values('5.0'); Can you provide a concrete example in which the text versus binary format changes the type inference behavior? Regards, Jeff Davis -- 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: Andrew McNamara on 7 Feb 2010 18:53 >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: http://code.google.com/p/ocpgdb/ As well as using the newer APIs, I have attempted to keep the code as simple as possible, eschewing things like threading as adding too much complexity for too little gain (particularly true of Python threading), and I kept to just the code DB-API functionality. The C code exists mainly to present a pythonic view of libpq. I found that type conversion and marshalling could generally be done from python with more than acceptable performance (via the C-coded "struct" module in the standard library for common types). In my tests, ocpgdb has performed at least as well as pyPgSQL and psycopg, often a lot better, primarily due to the use of the libpq binary protocols, I think. I'm not proposing my module as your canonical implementation, although you're welcome to it if you like. Rather, it demonstrates another viable approach, minimal, and using newer libpq APIs. BTW, with respect to the discussion of the Python DB-API - I see it as specifying a lowest-common-denominator, or the subset of functionality that should be available from most databases without requiring contortions. Like eating at McDonalds, it does the job, but it's never going to delight or surprise. A PostGreSQL blessed adapter really should provide access to all the features in libpq, and I'm not sure this is directly compatible with DBAPI. Instead, the DBAPI-compliance should be layered on top. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ -- 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: "Massa, Harald Armin" on 8 Feb 2010 06:55 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 challenge. A native Python implementation, without using libpq, will have to reimplement much of libpq - just let me isolate proper escaping, and will have its own bugs. Now, once *that* problem is under control, and there's a nicely licensed, > well documented, major feature complete, and good performing driver, at that > point it would be completely appropriate to ask "what about people who want > support for other Python platforms and don't care if it's slower?". Pure Pythondrivers do exist now; and they are allready discussed in the summaries - which is a good thing. With my remarks I just want to recommend that we at least should document a position for them; and a way ahead. And I need a place to point out that Python grew a FFI with ctypes. Maybe someone will think of a DBAPI2.0 compatible ctypes libpq wrapper ... Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger StraÃe 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality
From: Jeff Davis on 8 Feb 2010 01:56
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_Encoding Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |