Confusion over Python drivers
in [PgSql]
|
From: Andrew McNamara on 8 Feb 2010 17:15 >> 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, introducing a more compact, type-safe representation for a few >columns, without having to change all the existing Perl scripts >accessing the database. That's why I'm wondering... 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. I presume DBD::Pg is using text parameters, rather than binary. -- 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 03:14 >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-Python drivers: a) Python is no longer one-language, one-implementation. There are (at least) cPython (the original), Jython (on JVM), IronPython (from Microsoft on CLR), PyPy (Python on Python), Unladen Swallow (from Google on LLVM). In addition the nearly-Pythons as in Cython, RPython and ShedSkin Everything apart from cPython (and possible UnladenSwallow) has its challenges dealing with non-Python extension modules. From a developer standpoint it can be tempting to be able to rely on the same database adapter across more then one implementation b) the stabilization of an Python Application Binary Interface is in early discussion stage; meaning: it will take some time untill a non-Python extension can be usable across Python versions. c-Extensions are allways a major stumbling block on Python-n to Python-(n+1) versions c) Stability. Python code is same-on-same more robust then C-Code, as some of the crash-friendly-problems are eliminated (you cannot allocate memory wrongly within Python, you cannot errorly access memory cross array boundaries...) especially a) is a point to consider when standardizing on a PostgreSQL blessed Python-Postgresql-driver. How will the blessing extend to Jython / Ironpython / PyPy? 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 18:34 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 looks inside a literal of unknown type to try to determine its type -- it only looks at the context (to what function is it an argument?). For instance: SELECT '5'; -- has no idea what type it is SELECT '5' + 1; -- it's an int SELECT 'a' + 1; -- it's still an int ERROR: invalid input syntax for integer: "a" LINE 1: SELECT 'a' + 1; SELECT '5.0' + 1; -- still an int, bad input format ERROR: invalid input syntax for integer: "5.0" LINE 1: SELECT '5.0' + 1; 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 8 Feb 2010 18:46 >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 looks inside a literal of unknown type to try to >determine its type -- it only looks at the context (to what function is >it an argument?). > >For instance: > > SELECT '5'; -- has no idea what type it is > > SELECT '5' + 1; -- it's an int > > SELECT 'a' + 1; -- it's still an int > ERROR: invalid input syntax for integer: "a" > LINE 1: SELECT 'a' + 1; > > SELECT '5.0' + 1; -- still an int, bad input format > ERROR: invalid input syntax for integer: "5.0" > LINE 1: SELECT '5.0' + 1; 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. 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). -- 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: Jeff Davis on 8 Feb 2010 18:50
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 libpq-based drivers (which is repeated several times). I think it would be valuable to have a complete, pure-python driver available (like the JDBC driver). That's a large project, however. People who use a different python implementation understand that libraries might not be as plentiful. It will be a while before there are as many pure-python libraries as there are pure-java libraries. Right now what we need is a driver toward which we can confidently direct cPython users. It's faster to wrap libpq than to write a complete driver. And if we don't have such a driver, we risk alienating an important community for postgresql growth. So, the cost is lower and the benefits are higher for wrapping libpq for the cPython users. At least, that seems to be the case right now; things may change in the future. 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 |