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.
Indeed. The lack of rowid itself is not an issue. It's that someone could 
create a database using SQLite 3.8.x features, pass it on to someone with a 
SQLite 3.7 based app and run into runtime problems that they weren't expecting. 
We're looking for some way to reliably detect these kinds of cases or 
alternatively language to put in the spec to prevent this situation in the 
first place.

AFAICT there's no simple value in the database we can use to check for this. I 
mistakenly thought we could use the schema format number for this. Queries on 
sqlite_master could work but we would need to come up with a way to use this 
reliably. The suggested queries check for known problems. I'm worried that this 
will be an inherently brittle check since the next sqlite revision could 
introduce a new feature for which the spec has no checks in place.

Perhaps we should make the allowed DDL subset a part of the spec. That way we 
make explicit what is allowed and anything outside of that is forbidden.

Pepijn

Thinking about this further, it occurs to me that a brute force way of testing this would be to keep around a separate executable with a statically linked version of a minimum release of SQLite you want to support, and have it try to open and access a database to make sure it didn't have any unsupported database objects. (It would, BTW, also fail in the same way if there are any unrecognized functions in any check constraints, but that's probably OK.) Parsing the sqlite_master table for DDL SQL unsupported at a specified release would probably require extracting SQLite's SQL parser to perform correctly (but then, if you did that, you could extract the parser for your minimum release supported), which isn't exactly making things easy to use.

Peter

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

Reply via email to