Simon Slavin wrote:
> On 11 May 2012, at 3:36pm, Scott Ferrett
> <sc...@ferrettconsulting.com> wrote:
> 
>> If this is not possible, I can restrict this bit of code to only work on
>> UPDATE statements.  But that still leaves me with the problem of needing
>> the rowid of the row being updated.
> 
> The only supplied function is the one which returns the rowid from the most
> recent INSERT.  There are no equivalents for UPDATE or SELECT.  Short of
> parsing the SQL statements I don't know of a way to figure it out.
> 
> I do have one application which edits SELECT statements as follows: after the
> 'SELECT ' at the beginning, insert 'rowid,'.

SELECT * FROM foo ORDER BY 1; -- oops, adding column breaks ORDER BY
SELECT * FROM foo JOIN bar; -- oops, "rowid" ambiguous without "foo." or "bar."
SELECT * FROM foo GROUP BY t; -- oops, "rowid" is from random row
SELECT * FROM foo UNION SELECT * FROM bar; -- oops

IMO, such SQL statement manipulation is way too fragile to be used in any
semi-general purpose library. You'd better just export low-level blob API and
let library user worry about getting valid row-id, blob handle invalidation
rules and all.

> When it gets the results it
> strips the first column off of the results from the SELECT before returning
> the other columns to the calling function.  This works perfectly in the
> context of that app, which never uses JOIN, knows that every table has a
> "rowid" column, and knows that the calling function will never care about
> values in the "rowid" column.
> 
> Simon.

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

Reply via email to