Ann Harrison wrote:

>
> Not at the moment, though one is under discussion. It is likely
> that the first implementation will not include ranges ... i.e.
> we will offer LIMIT (<n>) but not LIMIT (<m>, <n>).
>
> Flames?
>

I understand your thought process here and it's fully driven by
implementation temptations. However, this LIMITed functionality won't
satisfy the needs of the people requesting the feature, as far as I
understand their requirements.

Apparently, there are simple, stateless search engines and web servers
that can't keep a database context (unlike NetFrastructure servers --
shameless plug!). So they issue the same query over and over again to
scroll a result set a page at a time. So, hypothetically speaking, if
someone goes to an online jobs site and searches for: "software manager
director" -- the site might return 200 hits. Each web page will return
10 rows at a time using some SQL statement of the form SELECT ... LIMIT
10*n, 10. It seems primitive to a non-marketer like myself but there
appears a real craving for this sort of functionality.

If the release cycle is that compressed or you're working off a
"rolling" release cycle, it makes sense to phase it in this way.
Otherwise, it shouldn't be that difficult to implement the full
functionality in a wider window.

Still you won't get flamed from the users who want the FIRST or TOP <n>
rows from a result set and you'll certainly never get flamed by me.

Regards,
Charlie