>On Tue, 13 Oct 1998, Bruce Momjian wrote:
>
>> My guess in a web application is that the transaction is started for
>> every new page, so you can't have transactions spanning SQL sessions.
>>
>> LIMIT theoretically would allow you to start up where you left off.
slightly off topic question, but how would this work? by doing an order by
and knowing the last record? or is this handled automatically in MySQL?
>
>************ EXACTLY !-)
>Plus, it could also be used to limit bogus-run-away queries.
i'm not really following this thread too closely (i'm reading but not always
thinking while i read) so i probably missed some things, but it seems to me
the query limit env. variable hack is a *good thing* (i would use it, at
least -- specifically to eliminate runaway queries, not so much to limit the
# of matches) and the cursor approach would be the *right way* but not
always the easiest way (in # of steps) or fastest way (because of the order
by/sort business -- i've been using cursors in web apps for a while now, so
i never noticed that this causes things to get ugly or think about why). i
can understand things getting ugly with joins and sorting, but on a plain,
single table select with no indexes (or even with indexes), which is
apparently the target of the todo item, i still don't get the difference.
you'd still be stuck scanning, which i would think would be the time
consuming part.
i guess that's why i'm just a lurker and not really a hacker, though.