I'm too used to having MySQL's LIMIT keyword which allows me to specify the starting row and number of rows returned, right in the SQL statement. I wonder why something that straightforward isn't built into most other DB servers (or standard SQL for that matter).

Because SQL is a set-oriented language (also, tables or relations from relational model don't have inherent ordering: they are also sets of rows; keys are the means of identifying, not ordering). Now, the question might be why are we using such a data access language from procedural languages... Well, SQL was originally intended to be an end-user language, not embedded one (figure that - giving your end-users unrestricted SQL!).

Anyway, my advice is to always try and use only standard language (and not the most recent standard!). If you succumb to temptation to massively use a nice non-standard feature (like I did with Informix temporary tables, vastly more convenient and usefull than those in, say, Oracle or DB2), you will get yourself in trouble sooner or later . At least have a strategy in place for replacing those machanism with standard ones.

Finally, test the impact of those 'firehose cursors' on performance of your app. If your web server and database server are either on the same machine or on reasonably fast and uncongested LAN, I suppose they are going to be small, if not negligible.

Let us know about results!

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green