Despite the long diatribes you have not indicated a single case in which the set ordinal of the row would be of any use whatsoever.
For 40 years we have gotten on without it, so yes, it is only for you newbies that somehow think there is a use for it, and for 40 years no one has ever come upon a real need to have set ordinals generated by the database engine as part of the cursor processing (for various definitions of database engine). Kind of makes you wonder what you might have overlooked or are assuming incorrectly doesn't it? > -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Olaf Schmidt > Sent: Saturday, 6 July, 2013 14:45 > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Is there a way to return the row number? (NOT > the rowid) > > Am 06.07.2013 18:58, schrieb j.merrill- > > > There are reasons to want what is in other SQL implementations > > implemented with "row_number() OVER (ORDER BY ...)" but > > "disconnected Recordsets" or for data "passed across thread- > > or machine-boundaries" are definitely NOT valid reasons. > > Since they are self-describing containers, which can be created > directly from an SQL-string, they allow for a sort of genericity > whilst designing applications, which just saves a lot of lines of > code - and a row_number(OptionalOffsetToStartFrom)-function *is* > much easier to notate in a View-Definition-script, than to implement > with dedicated lines of code in your programming-language of choice. > > Perhaps you think "loops" when you think about retrieving (or > visualizing) DB-Data - (and in this case it is easy to ensure > such a counter of course, if the loop is (or needs to be) always > already there in the first place). > > I think: "returned Set-Objects, based on a View-Name and some Params": > - and one line of code, to retrieve them by Command-Object or SQL- > string > > then I'm free to decide, what to do with that Set-Object... > e.g. direct visualizing in a Grid: > - also one line of code: Grid.DataSource = Recordset > > Or I decide to serialize it into a Byte-Array, to be able to > pass it into another thread - or pump it out over sockets, to > satisfy an RPC. > - also one line of code: ByteArray = Recordset.Content > > So far I *was* living without that row_number()-feature of course - > no need to explain to me, what can be done at the application-level > ... > I've perhaps forgotten more about efficient Application-programming, > than... - arrghh - no, let's not go there... ;-) > > > The "row number" value as commonly described in this thread is > > completely useless except in the context of one specific > > execution of a particular SQL statement. > > In the same spirit as you just wrote above, I could come up with: > "a Round()-function is completely useless, except in the context > of..." > or > "multiplying a Field-Value with a constant literal is completely > useless..." > or ... > > I can only repeat, what I already wrote in my reply to Keith - it's > only about (just another) convenience-feature - nothing more. > > > You would need to use the table's primary key value to do any > updates > > to the original table... > > ...to avoid updating rows that had been changed by other sessions > > users after the initial SELECT. > > What does this necessity have to do with my nice, new "per SQL > included > RowNumbering"-field (I'd otherwise would have to ensure with dedicated > "non SQL-code")? > > > You would definitely not want to relate one recordset to another > using the > > "row number" value, because executing the exact same SQL statement > 1 > second > > later could return a completely different "row number" value for > every primary key. > > Who said, that those who are asking for the inclusion of a row_number- > feature, are complete DB-newbies, who have to be thaught something as > primitive as the above? ;-) > > > Olaf > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
