On Thu, Aug 27, 2015 at 4:21 PM, Dominique Devienne <ddevienne at gmail.com> wrote:
> On Thu, Aug 27, 2015 at 3:37 PM, Richard Hipp <drh at sqlite.org> wrote: > >> On 8/27/15, Clemens Ladisch <clemens at ladisch.de> wrote: >> > Dominique Devienne wrote: >> >> how can we programatically reliably discover which (v)tables a view >> >> accesses, staying in documented behavior land? >> > >> > With an authorizer callback: >> > http://www.sqlite.org/c3ref/set_authorizer.html >> > >> >> Clever! I was about to write back that SQLite does not provide the >> capability that Dominique wants, but I think Clemens's answer is better! >> > > Thanks Clemens and Richard. If VTable names are reported, this will work > for us! > I'll try it, to move away from our current reliance on undefined behavior. > --DD > One annoyance with the authorizer approach is that you cannot "stack them", since there's no get_authorizer (or set_authorizer returning the old one). This is a large codebase, and it's also plugin-based, so knowing for sure who sets one if problematic and error prone. >From the doc: > Only a single authorizer can be in place on a database connection at a > time. > Each call to sqlite3_set_authorizer overrides the previous call. > Disable the authorizer by installing a NULL callback. > The authorizer is disabled by default. Any chance we could have a way to "stack" authorizers, in a future version of SQLite? I guess that could be viewed as a security hole, but then there's no action-code for calling set_authorizer apparently, so anyone can override any one authorizer already in place, no? Or am I missing something? Thanks, --DD
