Re: [DB-SIG] paramstyles, again

2007-05-23 Thread M.-A. Lemburg
On 2007-05-23 07:29, Carsten Haese wrote: > On Tue, 22 May 2007 17:08:46 -0400, Art Protin wrote >> Separating out the query would greatly reduce the confusion between >> parameters >> and string formatting as then the two would be in separate commands. > > Ah, you mean a "prepared statement" o

Re: [DB-SIG] paramstyles, again

2007-05-23 Thread M.-A. Lemburg
On 2007-05-22 16:16, Carsten Haese wrote: > This has been discussed before, but I'd like to re-cast a vote on this > for DB-API 3.0: > > * Deprecate/disallow pyformat/format paramstyles. +0 > * Make qmark the mandatory minimum paramstyle. Allowing additional > parameter styles (numeric and/or na

Re: [DB-SIG] paramstyles, again

2007-05-23 Thread Carsten Haese
On Wed, 2007-05-23 at 12:36 +0200, M.-A. Lemburg wrote: > Just an aside: > > Note that the named style allows binding the same parameter > more than once. Ditto for numeric style. > This poses a few problems for interfaces which > rely on the database telling the interface how to best bind > a p

Re: [DB-SIG] paramstyles, again

2007-05-23 Thread M.-A. Lemburg
On 2007-05-23 13:37, Carsten Haese wrote: > On Wed, 2007-05-23 at 12:36 +0200, M.-A. Lemburg wrote: >> Just an aside: >> >> Note that the named style allows binding the same parameter >> more than once. > > Ditto for numeric style. > >> This poses a few problems for interfaces which >> rely on th

Re: [DB-SIG] paramstyles, again

2007-05-23 Thread Carsten Haese
On Wed, 2007-05-23 at 13:52 +0200, M.-A. Lemburg wrote: > That's not what I was asking. The problem (or maybe it's a non-issue > in the real word) is: what happens at binding time to the data > fetched from the object you bind to a command parameter, e.g. > say the interface supports reading data f

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carl Karsten
Carsten Haese wrote: > On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >> Or some such abomination of results of one query as a parameter of a >> 2nd. >> >> given my use case, I can understand why this isn't in the spec, and >> why it may never be. but it seems to come up more often that

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carsten Haese
On Wed, 2007-05-23 at 13:13 -0500, Carl Karsten wrote: > list = rows > cSql = ("select ktbl2_fk from tbl3 where ktbl1_fk IN (" >+",".join("%s" for _ in list) >+")" ) > print cSql > cur.execute(cSql, list) Assuming that "rows" is the fetchall() result from your first query, try list = [x[0

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Chris Clark
Carl Karsten wrote: > Carsten Haese wrote: > >> On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >> >>> Or some such abomination of results of one query as a parameter of a >>> 2nd. >>> >>> given my use case, I can understand why this isn't in the spec, and >>> why it may never be.

Re: [DB-SIG] client side sub queries

2007-05-23 Thread M.-A. Lemburg
On 2007-05-23 20:37, Chris Clark wrote: > Carl Karsten wrote: >> Carsten Haese wrote: >> >>> On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >>> Or some such abomination of results of one query as a parameter of a 2nd. given my use case, I can understand why this

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carl Karsten
Chris Clark wrote: > Carl Karsten wrote: >> Carsten Haese wrote: >> >>> On Tue, 22 May 2007 17:33:27 -0500, Carl Karsten wrote >>> Or some such abomination of results of one query as a parameter of a 2nd. given my use case, I can understand why this isn't in the spec, a

Re: [DB-SIG] client side sub queries

2007-05-23 Thread Carl Karsten
Carsten Haese wrote: > On Wed, 2007-05-23 at 13:13 -0500, Carl Karsten wrote: >> list = rows >> cSql = ("select ktbl2_fk from tbl3 where ktbl1_fk IN (" >>+",".join("%s" for _ in list) >>+")" ) >> print cSql >> cur.execute(cSql, list) > > Assuming that "rows" is the fetchall() result from y