Re: [sqlite-dev] Proposed new sqlite3_open_v3() interface

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