Here's a thought: What does your hypothetical function return for a table
defined as follows:
CREATE TABLE strange(rowid TEXT, _rowid_ TEXT, oid TEXT);
That table has a rowid, but it is completely inaccessible to the application.
Does your function return TRUE or FALSE?
My point: I think any application that depends on there being a column named "rowid" that is the key to the table is already
broken. WITHOUT ROWID does not add any new brokenness.
Yeah, that Schema would break most systems depending on a rowid today even, regardless of rowid-less tables, so the danger is
ever-present. Point taken (and view shared) - but it won't be the first brokenness-habit to permeate SQL-programs the world over.
However, even if so broken, with a fix as easy as a single SQL query upon opening a table, I doubt the issue merrits any more time.
For Peter & Pepijn - I think the issue is essentially a forward-compatibility problem moreso than a backward-compatibility one. So I
think your idea on introducing some version control would be the least painful.
Thank you kindly.
*goes off to import TABLE strange() into some systems for fun*
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
