Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[James K. Lowden]

On Wed, 3 Jul 2013 22:49:51 -0500
"Jay A. Kreibich"  wrote:

>   So anyways, I don't actually care about the actual number of orders,
>   which is mostly likely what my SQL query returns, I just want the
>   ranking-- who is first, second, and third.  I can get that from an
>   ORDER BY query, but the data that makes up the result set doesn't
>   actually contain the information I want.  The information I want is
>   encoded into the row order of the result set, not the data values of
>   the result.  In other words, the row order is extremely relevant,
> and part of the desired result itself.   That's about as
> non-Relational as you can get.

I enjoyed your post, Jay, and hereby place my  bet that it wins HAVING
MAX(COUNT(words)) FROM sqlite-users for July.  ;-)  

I beg to differ on this bit of your analysis, though.  To say the
rank information you want is "encoded in the order" is like saying the
count information is encoded in the number of rows produced.  What you
really mean is that one is derived from the other.  True, you can infer
what you want to know from what you see, but you can also compute it
(by counting, or by counting the lessers).  Nothing non-relational
about it.  

> "Give me a list of the top 10 sales regions for
>   last quarter, ranked by total number of orders."
...
>   Of course the result is very non-Relational, since the inherent
>   information I asked for is dependent on row order

No row order is implied.  Rank depends not on *row* order, but on total
number of orders.  There is no reason the rows couldn't be displayed in
another order (say, by region name) causing their ranks to appear in
4,3,6,8,9,2... order.  The fact that the query can be expressed in SQL
without reference to a row number confirms the point.  

That's good news: the relational heart of SQL, however trampled and
starved, still beats on.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Jean-Christophe Deschamps]

At 05:49 04/07/2013, you wrote:
´¯¯¯

  But in the bigger context of this discussion, I think SQLite might
  consider a row_number() function, or (my personal preference) some
  type of virtual column, such as "_row_number_".  I suggest that term,
  since that's what Oracle, MS SQL Server, and PostgreSQL use.  I
  prefer the idea of a virtual column because, unlike a function, it is
  difficult to misuse a virtual column in some other context.  If it
  can only be expressed in a result set selector (the SELECT clause),
  it will only work there.


While I understand your arguments in favor of this feature and I 
believe it could be used without adding much bloat, allow me to be the 
devil's advocate for a while.



  -- There are other ways of doing this in SQL.

  Umm, exactly?


You will certainly agree that a ranking feature is not going to be used 
in most queries. It only serves in relatively rare cases.


OTOH as your example shows the usefulness of a ranking function is 
merely limited to small result sets where ranking has a meaning for 
humans. What I mean here is that you're more likely to be interessed in 
the top 10  than in the  having ranks between 
123456779 and 123456789. Top 10 or 100 or 1000 but never top billion.


Unless you have an exceptional use case ranked result sets are more 
likely to be small.


At this point why not use one of the SQL way to do it, using a temp 
table or view to get the new rowid do the ranking automagically?


Using memory as temp store this will add little overhead to such rarely 
used queries. Even where temp store is set to disk and carved in stone 
by compile-time option the overhead should be minimal due to the 
typical small number of rows involved in the result set.


I don't buy your argument that the rank should in theory be an explicit 
part of the result set, contrary to autoincrement rowid bumping from 1.



So if you want a view that provides
  any type of ordering, you need to be able to provide a rank column as
  part of the view result.


You never need to query for the top 10 sales region every tenth of a 
second (or you're a burnt out sales manager).


On the contrary I'd say that a rank is the result of some sort 
depending on values spread in joined tables. When those values get 
inserted or otherwise updated, the rank is likely to change. Keeping it 
as an explicit column then means significant overhead.


Or did I misunderstand your statements on this point?


  -- You can just do it in code.

  Well sure.


Not so sure: for instance using the CLI doesn't allow any kind of 
"programming".



--
j...@antichoc.net  


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Jay A. Kreibich]

On Tue, Jul 02, 2013 at 11:40:34AM +0100, Alex Bowden scratched on the wall:
> 
> The SQL standard has always been a moving feast, chasing the field
> implementations, perfectly capable of going back on it's earlier
> mistakes,  the main purpose of which, on a good day, is to promote
> standardisation of SQL implementations and try and keep to the
> Relational Theory model where practical considerations allow.
> 
> So, if the SQL standard has drifted toward requiring "in the order
> in which they are defined in the table definition"  to be meaningful,
> then this is an oversight that would likely be corrected when somebody
> has an in the field SQL database which, correctly, enforces no such
> concept.

  I realize that historically the SQL standards have been somewhat liquid,
  and that the standards often follow the implementations (although not
  so much in the last 20 years).  This is not some small misstep, however.
  The concept that columns have order, and are defined and referenced by
  that order, is baked deep, deep into the SQL language, environment,
  and every SQL operation.  It isn't just some after-thought in a newer
  version of the standard.

  As I said before, SQL has very poor and highly ambiguous naming conventions 
  (nevermind standards) for result set columns.  Trying to define
  columns by their names in an SQL environment would be extremely
  difficult and require a massive overhaul of SQL and every database
  out there.  While it may be a bit ugly and non-Relational to have a
  defined column order, it rarely matters.  Unlike row order, there
  aren't performance concerns in a row-based database-- the query
  optimizer has little to gain by allowing arbitrary column ordering.
  
  This is a reason nearly every database API provides access to
  results by column index.  In the SQLite API, column index is the
  *ONLY* way to retrieve a value (or, for that matter, a column name).
  Even if it wasn't part of the standard, reordering the column results
  of a "*" would break almost every application written in the last 35
  years that uses that type of query.

> People should not be encouraged to become more dependent on the use of
> such temporary misfeatures.

  I agree that good database engineers should have a strong
  understanding of Relational Model and-- given the choice-- should
  tend to default to doing things "the Relational way", but back in
  reality, that's not the world we live in.  SQL is not the Relational 
  Model, and the Relational Model is not SQL.  Every practical RDBMS out
  there uses SQL, so every good database engineer should be equally
  versed in SQL, and the differences between SQL and the Relational Model.

  Sometimes you can approach a problem in a very Relational way, but still
  express it in SQL.  Many times you cannot.  Fighting SQL and going
  against its design concepts just to satisfy some desire to do things
  the theoretically pretty way is likely to result in making thing
  overly complex and poor performance.  If you're working in SQL, doing
  it the "SQL way" isn't inherently evil, especially if you know enough
  to understand why you're diverging from the Model, and why it makes
  sense in SQL.

  If you try to make your C++ look and act exactly like Smalltalk, you'll
  end up writing something that is even uglier than standard C++.  Using
  ideas and concepts from Smalltalk to better your C++ programs and OOP
  designs is good engineering.  Forcing something that isn't meant to
  be is not.

  The same applies to SQL and the Relational Model.

> In context, the particular focus of your objection to the
> relational approach, seems irrelevant.

  Yes and no.  I have great respect for the Relational Model, and think
  every database programmer worth anything should have a deep
  understanding of it... Not the Relational Model through SQL, but the
  Model itself, unencumbered by everything SQL brings to the table.
  They should also know SQL, and where the environments differ.  If anyone
  cares, I can provide a list of good books (most by C.J. Date).

  But in the bigger context of this discussion, I think SQLite might
  consider a row_number() function, or (my personal preference) some
  type of virtual column, such as "_row_number_".  I suggest that term,
  since that's what Oracle, MS SQL Server, and PostgreSQL use.  I
  prefer the idea of a virtual column because, unlike a function, it is
  difficult to misuse a virtual column in some other context.  If it
  can only be expressed in a result set selector (the SELECT clause),
  it will only work there.



  It is easy to say such a feature it isn't Relational.  But guess what...
  result sets aren't Relational, even in a pure Relational Model environment.
  In fact, that's why they're called "result sets" rather than
  "result relations" or (in SQL) "result tables."  Yes, the name "set"
  is not the best choice, but the difference in terms is no casual accident.
  Results specifically 

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[James K. Lowden]

On Mon, 1 Jul 2013 23:30:10 -0500
"Jay A. Kreibich"  wrote:

>   While rearranging the column order may not functionally change the
>   answer, a database is not given that flexibility in SQL.  For
>   example, "SELECT *" *must* return the columns in the order they are
>   defined in the table definition.  It isn't that most databases just
>   happen to do this-- the column order is actually predicated by the
>   standard.

Thank you for the clarification; I didn't know the standard addressed
that. I find the standard hard to read, even by the standard of
standards.  And, after all, it's pretty safe to ignore: that what most
products do when it suits them!  

> > "sort by *" would imply that the order of the columns returned by
> > '*' is meaningful, which it is not.  "sort by the arbitrary order
> > produced by 'select *'" isn't even deterministic.  
> 
>   In SQL column order *is* deterministic, so the sort order would also
>   be deterministic.  Likely meaningless, but still deterministic.

Yes, I was musing about that today.  "sort by *" could certainly be
deterministic, depending on how it's defined.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Alex Bowden]

The SQL standard has always been a moving feast, chasing the field 
implementations, perfectly capable of going back on it's earlier mistakes,  the 
main purpose of which, on a good day, is to promote standardisation of SQL 
implementations and try and keep to the Relational Theory model where practical 
considerations allow.

So, if the SQL standard has drifted toward requiring "… in the order in which 
they are defined in the table definition…"  to be meaningful,   then this is an 
oversight that would likely be corrected when somebody has an in the field SQL 
database which, correctly, enforces no such concept.

People should not be encouraged to become more dependent on the use of such 
temporary misfeatures.

In context, the particular focus of your objection to the relational approach,  
seems irrelevant.

>> "sort by *" would imply that the order of the columns returned by '*' is
>> meaningful, which it is not.  "sort by the arbitrary order produced by
>> 'select *'" isn't even deterministic.  
> 
>  In SQL column order *is* deterministic, so the sort order would also
>  be deterministic.  Likely meaningless, but still deterministic.


Sort order isn't necessarily deterministic even if we know the column order.  
So the possibility that we may not know it, makes life no worse.
 

On 2 Jul 2013, at 05:30, Jay A. Kreibich  wrote:

> On Mon, Jul 01, 2013 at 10:52:20PM -0400, James K. Lowden scratched on the 
> wall:
> 
>> "select *" is shorthand for "all columns". You'll note that what's
>> returned isn't some kind of special '*' column, but all columns.  The
>> order in which the columns are returned isn't meaningful because the
>> colums have labels -- names -- to tell you which is which.  Rearranging
>> the column order doesn't change the answer.  
> 
>  That's not quite true.
> 
>  What you say is more or less true in pure Relational Theory.  Under
>  Relational Theory, relational attributes (columns) are a proper set.
>  The columns have no defined order (just as rows have no defined
>  order), and can only be definitively reference by name.
> 
>  In SQL, columns are *not* a set.  The order of the columns in any SQL
>  query or operation is strictly defined.  Columns cannot be referenced
>  by name, because SQL allows name-less columns (SELECT 1, 1, 1;) and
>  multiple columns with the same name (SELECT 1 A, 1 A, 1 A;).  SQL
>  doesn't even strictly define the column name for a calculated column
>  (SELECT avg( 1 )) and allows the DB to make up its own names.  SQLite
>  used to have several PRAGMAs to control short and long column names.
> 
>  Rather, in SQL, a column is definitively defined by its positional
>  index in the table or result set.  This is also why so many SQL APIs
>  allow you to fetch column values by index, rather than by name (which
>  would be a totally broken and dangerous API if columns could move
>  around).  It gets pretty messy...  The SQL standard goes to some
>  length to define a specific column order for stuff like JOIN operations,
>  including edge-case details like NATURAL JOINs where the number of
>  columns is reduced and somewhat ambiguously named.
> 
>  While rearranging the column order may not functionally change the
>  answer, a database is not given that flexibility in SQL.  For
>  example, "SELECT *" *must* return the columns in the order they are
>  defined in the table definition.  It isn't that most databases just
>  happen to do this-- the column order is actually predicated by the
>  standard.
> 
>> "sort by *" would imply that the order of the columns returned by '*' is
>> meaningful, which it is not.  "sort by the arbitrary order produced by
>> 'select *'" isn't even deterministic.  
> 
>  In SQL column order *is* deterministic, so the sort order would also
>  be deterministic.  Likely meaningless, but still deterministic.
> 
> 
>   -j
> 
> -- 
> Jay A. Kreibich < J A Y  @  K R E I B I.C H >
> 
> "Intelligence is like underwear: it is important that you have it,
> but showing it to the wrong people has the tendency to make them
> feel uncomfortable." -- Angela Johnson
> ___
> 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

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Jay A. Kreibich]

On Mon, Jul 01, 2013 at 10:52:20PM -0400, James K. Lowden scratched on the wall:

> "select *" is shorthand for "all columns". You'll note that what's
> returned isn't some kind of special '*' column, but all columns.  The
> order in which the columns are returned isn't meaningful because the
> colums have labels -- names -- to tell you which is which.  Rearranging
> the column order doesn't change the answer.  

  That's not quite true.

  What you say is more or less true in pure Relational Theory.  Under
  Relational Theory, relational attributes (columns) are a proper set.
  The columns have no defined order (just as rows have no defined
  order), and can only be definitively reference by name.
 
  In SQL, columns are *not* a set.  The order of the columns in any SQL
  query or operation is strictly defined.  Columns cannot be referenced
  by name, because SQL allows name-less columns (SELECT 1, 1, 1;) and
  multiple columns with the same name (SELECT 1 A, 1 A, 1 A;).  SQL
  doesn't even strictly define the column name for a calculated column
  (SELECT avg( 1 )) and allows the DB to make up its own names.  SQLite
  used to have several PRAGMAs to control short and long column names.
  
  Rather, in SQL, a column is definitively defined by its positional
  index in the table or result set.  This is also why so many SQL APIs
  allow you to fetch column values by index, rather than by name (which
  would be a totally broken and dangerous API if columns could move
  around).  It gets pretty messy...  The SQL standard goes to some
  length to define a specific column order for stuff like JOIN operations,
  including edge-case details like NATURAL JOINs where the number of
  columns is reduced and somewhat ambiguously named.

  While rearranging the column order may not functionally change the
  answer, a database is not given that flexibility in SQL.  For
  example, "SELECT *" *must* return the columns in the order they are
  defined in the table definition.  It isn't that most databases just
  happen to do this-- the column order is actually predicated by the
  standard.

> "sort by *" would imply that the order of the columns returned by '*' is
> meaningful, which it is not.  "sort by the arbitrary order produced by
> 'select *'" isn't even deterministic.  

  In SQL column order *is* deterministic, so the sort order would also
  be deterministic.  Likely meaningless, but still deterministic.


   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Roman Fleysher]

Bravo Alex !!


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Alex Bowden [a...@designlifecycle.com]
Sent: Monday, July 01, 2013 12:34 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe  rowid)

> OK, you don't agree.  Your opinion!  (That doesn't make you right, though!)

If you approach the government france and explain that you're not really very 
good at French,  but if they made the following list of Chinese language 
inclusions into French, then it would make it easier for you to write your 
"thank you letter" to your auntie Marie,  than I'm sure they would oblige.

And even if they didn't it wouldn't make you wrong.

You are proposing changes to a relational database management system that 
damage its relationality, on the basis that you don't understand how to use 
relational databases properly, and it would make your life easier.

In defending maintaining the relationality, I don't really need to be right.  
The onus is on you to justify the change that you propose.


On 1 Jul 2013, at 16:36, Tony Papadimitriou  wrote:

> OK, you don't agree.  Your opinion!  (That doesn't make you right, though!)
>
>> I'm sure there will be a SQL engine somewhere that will do it for you.
>
> We're talking about SQLite here, aren't we?  If some other database can do 
> it, then you should also consider that it may also be able to do what this 
> 'row' function.  (e.g. MySQL).  So, your point it moot.
>
>>> So, why make it sound like I don't know what I'm talking about?
>> I think you beat me to it.
>
> No comment!
>
> -Original Message- From: Alex Bowden
> Sent: Monday, July 01, 2013 6:17 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)
>
> ___
> 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


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[James K. Lowden]

On Mon, 1 Jul 2013 14:22:53 +0300
"Tony Papadimitriou"  wrote:

> Just because you can select something doesn't mean you have to be 
> able to sort by it.  

Yes, it does. 

> Can you sort by * (select * by table sort by *)?  

You have confused syntax with semantics.  

"select *" is shorthand for "all columns". You'll note that what's
returned isn't some kind of special '*' column, but all columns.  The
order in which the columns are returned isn't meaningful because the
colums have labels -- names -- to tell you which is which.  Rearranging
the column order doesn't change the answer.  

"sort by *" would imply that the order of the columns returned by '*' is
meaningful, which it is not.  "sort by the arbitrary order produced by
'select *'" isn't even deterministic.  

> So, why make it sound like I don't know what I'm talking about?

Ahem.  

--jkl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Keith Medcalf]

Yes, you can sort by *

> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Tony Papadimitriou
> Sent: Monday, 1 July, 2013 05:23
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe
> rowid)
> 
> Please!  Just because you can select something doesn't mean you have
> to be
> able to sort by it.  Can you sort by *
> (select * by table sort by *)?  So, why make it sound like I don't
> know what
> I'm talking about?
> 
> -Original Message-
> From: Alex Bowden
> Sent: Monday, July 01, 2013 2:07 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe
> rowid)
> 
> > This would not be something you would sort by.
> 
> And what if I do?
> 
> > It should be assigned a value only during final 'display' of the
> query
> > after all 'sorts' of operations are done with.
> 
> Oh great.  So the user is supposed to understand the implementation,
> in
> order to understand what the results will be.
> 
> 
> This would be just another nail in the coffin of relationality and
> simplicity, on a minor whim.
> 
> ___
> 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

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Alex Bowden]

> OK, you don't agree.  Your opinion!  (That doesn't make you right, though!)

If you approach the government france and explain that you're not really very 
good at French,  but if they made the following list of Chinese language 
inclusions into French, then it would make it easier for you to write your 
"thank you letter" to your auntie Marie,  than I'm sure they would oblige.

And even if they didn't it wouldn't make you wrong.

You are proposing changes to a relational database management system that 
damage its relationality, on the basis that you don't understand how to use 
relational databases properly, and it would make your life easier.

In defending maintaining the relationality, I don't really need to be right.  
The onus is on you to justify the change that you propose.


On 1 Jul 2013, at 16:36, Tony Papadimitriou  wrote:

> OK, you don't agree.  Your opinion!  (That doesn't make you right, though!)
> 
>> I'm sure there will be a SQL engine somewhere that will do it for you.
> 
> We're talking about SQLite here, aren't we?  If some other database can do 
> it, then you should also consider that it may also be able to do what this 
> 'row' function.  (e.g. MySQL).  So, your point it moot.
> 
>>> So, why make it sound like I don't know what I'm talking about?
>> I think you beat me to it.
> 
> No comment!
> 
> -Original Message- From: Alex Bowden
> Sent: Monday, July 01, 2013 6:17 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)
> 
> ___
> 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

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Tony Papadimitriou]

OK, you don't agree.  Your opinion!  (That doesn't make you right, though!)


I'm sure there will be a SQL engine somewhere that will do it for you.


We're talking about SQLite here, aren't we?  If some other database can do 
it, then you should also consider that it may also be able to do what this 
'row' function.  (e.g. MySQL).  So, your point it moot.



So, why make it sound like I don't know what I'm talking about?

I think you beat me to it.


No comment!

-Original Message- 
From: Alex Bowden

Sent: Monday, July 01, 2013 6:17 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe 
rowid)


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Alex Bowden]

> Please!  Just because you can select something doesn't mean you have to be 
> able to sort by it.

There are a small number of exceptions,  each of which is a bodge.

But some bodges are worth the impact.

>  Can you sort by *

* is a very useful and largely harmless bodge.

There is fundamentally no reason why you shouldn't be able to to sort by *.  
But people usually care about the order of field in a sort.  

> (select * by table sort by *)?  

I'm sure there will be a SQL engine somewhere that will do it for you.

It would require no additional documentation or code.  In fact it might require 
extra, to prevent it.  It's pointless,  but benign.

> So, why make it sound like I don't know what I'm talking about?

I think you beat me to it.

> 
> -Original Message- From: Alex Bowden
> Sent: Monday, July 01, 2013 2:07 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)
> 
>> This would not be something you would sort by.
> 
> And what if I do?
> 
>> It should be assigned a value only during final 'display' of the query after 
>> all 'sorts' of operations are done with.
> 
> Oh great.  So the user is supposed to understand the implementation, in order 
> to understand what the results will be.
> 
> 
> This would be just another nail in the coffin of relationality and 
> simplicity, on a minor whim.
> 
> ___
> 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

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[Tony Papadimitriou]

Please!  Just because you can select something doesn't mean you have to be 
able to sort by it.  Can you sort by *
(select * by table sort by *)?  So, why make it sound like I don't know what 
I'm talking about?


-Original Message- 
From: Alex Bowden

Sent: Monday, July 01, 2013 2:07 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Is there a way to return the row number? (NOTthe 
rowid)



This would not be something you would sort by.


And what if I do?

It should be assigned a value only during final 'display' of the query 
after all 'sorts' of operations are done with.


Oh great.  So the user is supposed to understand the implementation, in 
order to understand what the results will be.



This would be just another nail in the coffin of relationality and 
simplicity, on a minor whim.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users