[DB-SIG] Result Set Inconsistencies

[Chris Cogdon]

On Wednesday, Jul 16, 2003, at 14:02 US/Pacific, Danny Yoo wrote:

> However, there is a fundamental difference between tuples and lists:
> they don't compare!
>
> ###
>>>> (1, 2) == [1, 2]
> 0
> ###
>
>
> In this case, I agree that the standard needs to be specific about what
> kind of sequence is used to bundle up result sets.  It's terrible to 
> think
> that something innocent like:
>
> ###
> cursor.execute("select name, email from people")
> if ('dyoo', 'dyoo at hkn.eecs.berkeley.edu') in cursor.fetchall():
>     print "I'm in there!"
> ###
>
> won't work in Oracle simply because each result row is a list.

I'm sure we're both aware that your example could be MUCH better 
written with a little more intelligent SQL :) But, yes, I know it's 
just an example.

For good or bad, implementers have decided to interpret 'sequence' in 
their own way. pyPgSQL's intelligent 'PgResultSet' is quite flexible 
(at the sacrifice of speed, as I've pointed out in previous 
discussions). At this stage of the game, I think forcing everyone to a 
particular interpretation of 'sequence' is not on the cards, and you 
should code your applications accordingly.

For example

 >>> results = (1,2) # just for sake of example
 >>> results == [1,2]
0
 >>> list(results) == [1,2]
1

Ie, if you're doing such direct comparison against lists, make sure you 
actually have a list you're comparing with.

(in this case, converting to tuples might be better)


-- 
    ("`-/")_.-'"``-._        Chris Cogdon <chris at cogdon.org>
     . . `; -._    )-;-,_`)
    (v_,)'  _  )`-.\  ``-'
   _.- _..-_/ / ((.'
((,.-'   ((,/   fL