Simon has the correct idea. If you have a function x(), you are free to
define another in the same extension called function x_config(<args>).
This x_config() function is free to change global runtime preference
variables of the x() function based on the <args> passed into the last call
of x_config(). SQLITE_DETERMINISTIC is merely a performance hint for
expression evaluation within a single statement. Deterministic functions
may be called multiple times anyway and every distinct statement where
output depends on a function, deterministic or not, will cause that
function to be evaluated at least once.
The only problem will be if a thread in your process calls the x_config()
function while the x() function has a different thread context. If
overlapping multithreaded usage is anticipated, global configuration
variable access must be serialized by the sqlite3 mutex API or other
critical section mechanism.
On Tue, Feb 6, 2018 at 1:24 AM, Ulrich Telle <ulrich.te...@gmx.de> wrote:
> > Simon Slavin wrote:
> > On 6 Feb 2018, at 8:33am, Ulrich Telle wrote:
> > > Another possibility would be to add a user-defined function for the
> > > configuration of the extension that could be called from a SELECT
> > > statement:
> > >
> > > SELECT myextension_config('param-name', 'param-value');
> > I've seen this done before. Of course it means that your normal
> function is not deterministic, so you may no longer use
> SQLITE_DETERMINISTIC . This is in contrast to a function where parameters
> are set during compilation.
> Well, actually my goal is not to have an extension with non-deterministic
> functions. The parameters have mostly the purpose to initialize the
> extension (things similar to what you do to SQLite itself with pragmas like
> "PRAGMA cache_size", or "PRAGMA data_store_directory"). The extension would
> accept changes to the parameters only before the first invocation of the
> extension functions.
> sqlite-users mailing list
sqlite-users mailing list