Hi James,
About complexity: I'm not sure it's NlogN; for each N you need to count
N-1 columns, that's N^2 IMO.
And you have an EXTRA temporary B-TREE? Doesn't it matter??
Although I don't really understand why, it has an index on it.
My original concern is indeed simplicity and efficiency.
But I'm NOT advocating any complex RANK function, but rather to expose
(as pseudo-data) the row index IN THE CURRENT RESULT SET; while usually
the result set is ordered, it doesn't really matter. This information
HAS NO other technical meaning (like rowid).
Like having about a list (on paper) containing (pseudo) RANDOM data and
telling someone "look at 13th row"; by 13th I mean exactly as the list
is printed.
The other one can much easily spot 13 if available than to quickly count.
If instead of row number I use "the row having xxx in it", the other one
has to do some visual search (binary if the data would be sorted).
Now all I say is, if I print the list from my code I can simply generate
such info.
But it would be greatly simplified if I can have it from SQL without
complex/inefficient constructs, especially because it already does
something similar for LIMIT.
Of course I have to accept "no" as an answer if most people are against
this idea.
Regards,
Gabriel
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
