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 [1] 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 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. [1] https://www.sqlite.org/src/tree?name=ext/misc _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
