[DB-SIG] Result Set Inconsistencies
chris at cogdon.org
Wed Jul 16 16:08:18 EDT 2003
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]
> 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
> 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.
>>> results = (1,2) # just for sake of example
>>> results == [1,2]
>>> list(results) == [1,2]
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
More information about the DB-SIG