Dominique Devienne wrote:
> On Tue, Feb 6, 2018 at 11:15 AM, Ulrich Telle <ulrich.te...@gmx.de> wrote:
> > > An alternative is to expose a virtual table with a fixed set of rows, and
> > > accepting updates on the values, which can also then be "typed" too.
> > > But that's a lot more complicated though.
> > > (and refusing inserts/deletes too, of course).
> > >
> > > That vtable could also expose version information for the extension, for
> > > example, and those would be read-only. Just thinking aloud.
> > > Avoids non-deterministic functions.
> > A vtable with a fixed number of rows, one for each config parameter - this
> > approach sounds interesting.
> > I'll have to investigate how complicated it will be to implement such an
> > approach.
> This approach could IMHO be one of the contributed vtable impls in ext/misc
>  to be reused by other loadable extension authors, and could become the
> "semi official" way to solve that problem, lacking extension specific
> pragmas that is. My $0.02c. --DD
In case I'll implement the vtable approach, I might consider to make it
> PS: There's also always environment variables, especially for 1-time at
> startup settings.
> My main beef against env.vars. though is that they are not discoverable
> and often hidden.
For my purpose environment variables are not suitable. The user should be able
to alter the configuration parameters for each database connection.
sqlite-users mailing list