Loading...

sqlite-dev@sqlite.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [sqlite-dev] Proposed new sqlite3_open_v3() interface Mark Spiegel Mon May 03 13:00:29 2010

It would be nice to pass additional flags to custom VFS implementations via the "options" argument as well. Currently SQLite scrubs off any additional options in the internal open call before passing it on to the VFS. This would be a change to v2 and not require a v3.

D. Richard Hipp wrote:
On May 3, 2010, at 12:14 PM, Jim Morris wrote:

Adding another, optional, argument for "options" might eliminate the
need to create another interface version, v,4 down the road as new
features are added.  A text compatibility code might suffice.

The 3rd argument already is an "options". Your idea is a good one. Rather than create open_v3, just continue to use open_v2 but provide a new flag:

     SQLITE_OPEN_NO_LEGACY

Or some such....

On 5/3/2010 7:47 AM, D. Richard Hipp wrote:
Community feedback is requested for the following proposed new SQLite
C API:

    int sqlite3_open_v3(const char*, sqlite3**, int, const char*);

The new database connection constructor would work exactly like
sqlite3_open_v2() with the following exceptions:

(1) Foreign Key constraints would be enabled by default.
(2) Recursive triggers would be enabled by default.
(3) The default database file format would be format 4 (meaning that
new databases would be unreadable by versions of SQLite prior to 3.1.3).
(4) The misfeature of allowing double-quoted identifiers to fall back
to being strings if no matching identifier could be found would be
disabled.
(5) PRIMARY KEY columns would automatically be NOT NULL.  (The would
not change the current INTEGER PRIMARY KEY behavior, only non-INTEGER
PRIMARY KEYs.)

We are very hesitant to make any of the above changes to SQLite for
the default case since they run the risk of breaking legacy code.  By
making the newer behavior the default only for the new interface
sqlite3_open_v3() and leaving the behavior unchanged for legacy
constructors, we hope to encourage newer applications to use the newer
features while avoiding breakage of older applications.

Question 1:  Are there any objections to this approach?

Question 2:  Are there other foibles that we could correct using
sqlite3_open_v3?

D. Richard Hipp
[EMAIL PROTECTED]



_______________________________________________
sqlite-dev mailing list
[EMAIL PROTECTED]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-dev


_______________________________________________
sqlite-dev mailing list
[EMAIL PROTECTED]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-dev

D. Richard Hipp
[EMAIL PROTECTED]



_______________________________________________
sqlite-dev mailing list
[EMAIL PROTECTED]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-dev

_______________________________________________
sqlite-dev mailing list
[EMAIL PROTECTED]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-dev