Cannot step through asynchronous iterator manually

[Chris Angelico]

On Sun, Jan 31, 2016 at 9:05 AM, Michael Torrie <torriem at gmail.com> wrote:
> On 01/30/2016 02:57 PM, Michael Torrie wrote:
>> SELECT count(some_id_field),field1,field2,field3 FROM wherever WHERE
>> conditions
>>
>> If the first column (or whatever you decide to alias it as) contains a
>> count, and the rest of the information is still there.  If count is 1,
>> then the row is what you want and you can do whatever you wish with it.
>>  If not, throw your exception.
>
> I'm not sure how SQLite handles it, or even what the SQL spec says, but
> I know in MySQL you could do something like this:
>
> SELECT count(id) as row_count,`tablename`.* FROM `tablename` WHERE condition
>
> and get the same thing as SELECT * would have, with the addition of a
> "row_count" field.  Note that because of the count() part, the query
> will always only return 1 row. The fields will be NULL if the count was
> zero or they will contain the fields from the last row the query found.
>  In other words if there is more than one row that matches the query, it
> will only give you data from the last match.

Huh. Thank you, MySQL, for violating the spec in a different way from
what other servers do. The spec says you can't mix count(id) and
non-aggregated columns; other DBMSes permit this by cloning the ID
down all the rows, not by limiting the result to one row.
(Fortunately, nobody would ever run that on any other DBMS, as you use
the MySQL-specific backticks. Why that non-standard quoting convention
became the normal way to do things in MySQL, I don't know. It's really
annoying when I'm porting someone else's code to PostgreSQL.)

> Now if Frank is hoping to do work on the first row and then throw an
> exception if there's an additional row, then this of course won't work
> for him.

Exactly. If all he wants is to ignore additional rows, it's half the
work - and half the assertion protection.

ChrisA