Confusion over Python drivers
in [PgSql]
|
From: Tom Lane on 11 Feb 2010 00:46 Andrew McNamara <andrewm(a)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(), 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 from parts somewhere along the way. regards, tom lane -- 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 11 Feb 2010 01:04 >> 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 from parts somewhere along the way. The point is that if the driver is doing the right thing, the user of the driver at least has to choice to do things safely. -- 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: "Greg Sabino Mullane" on 11 Feb 2010 12:08 -----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 address this specific case, but it's ugly and not general. The right > thing is to set the correct type when you're marshalling the parameters... Well, ugly is in the eye of the beholder, and it certainly is a general solution. Any query with ambiguity in its parameters should explicitly declare the types, inside the query itself. Having the driver indicate the type should be the exception, not the rule. - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201002091811 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE -- 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: Tom Lane on 12 Feb 2010 09:31 Andrew McNamara <andrewm(a)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 parameter data. Indeed, and the above locution does set that. regards, tom lane -- 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 12 Feb 2010 20:07
>Andrew McNamara <andrewm(a)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 parameter data. > >Indeed, and the above locution does set that. Sure, but it requires the driver to modify the query - that isn't reasonable or practical. Expecting the user to the driver to know and correct set the type the driver will ultimately see is a recipe for disaster. -- 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 |