On 2/5/17, Richard Newman <rnew...@mozilla.com> wrote:
> Hello folks,
>
> `sqlite3_limit` allows callers to discover the run-time value of limits
> such as `SQLITE_LIMIT_VARIABLE_NUMBER`.
>
> Callers can also *set* each limit, so long as the value is smaller than a
> compile-time define, in this case `SQLITE_MAX_VARIABLE_NUMBER`.
>
> But callers have no good way of determining the largest acceptable value:
> they must do one of three things.
>
> 1. Be compiled at the same time as sqlite3.c and sniff the environment.
> Obviously this isn't possible for systems that don't control their own
> SQLite library.
> 2. Make sure to call `sqlite3_limit` when opening the first database
> connection, and save the returned value.
> 3. Discover the acceptable maximum for an existing connection by changing
> the limit: calling `sqlite3_limit` with a huge value, then calling it again
> with -1 to fetch the truncated value. (Or calling *three* times to fetch,
> change, restore.)
>
> Is this a deliberate omission?
We do strive to contain unnecessary growth in the number of
interfaces. Remember that we are promising to support every interface
until 2050. That argues for keeping the number of APIs to a minimum.
I think solution (3) above works well in this case, does it not? The
function to discover the compile-time upper bound on a limit while
keeping the current limit setting the same looks like this:
int compileTimeMaxLimit(sqlite3 *db, int eCode){
int iOriginalLimit = sqlite3_limit(db, eCode, 0x7fffffff);
return sqlite3_limit(db, eCode, iOriginalLimit);
}
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
