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 > [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
In case I'll implement the vtable approach, I might consider to make it available. > 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. Regards, Ulrich _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
