Re: creating tables needed for a query on-demand

Ed Pasma wrote:
> Hello Ryan, using the authorizer seems not to "hacky", at least you  
> rely on SQLite's own parser. As yiu found, the authorizer is only  
> invoked if there are no errors, so the tables must at least exist.  
> But another restriction to be aware of is that it only applies to  
> statement preparation. So, whith the PySQLite statement cache, it  
> will not work the second time a statement is executed, if that may  
> happen.
>
>   
ooh, thanks for the heads-up. I wasn't aware of the statement cache. I 
couldn't find much info about it, but from what I did find, it seems 
like it basically just caches the parse tree - not the results of the 
query or permissions. (ie the just the COMPILE step, but not the EXECUTE 
step, assuming the authorizer is called during the EXECUTE step)

another implication of your statement would be that permissions as 
controlled by the authorizer are determined the first time a given query 
is executed, but after that can only change if the entry is flushed from 
the statement cache. this seems like an odd design decision, are you 
sure it works this way?

I implemented the solution I described in my previous post, and it seems 
to be working, with the authorizer being called for every query.
> By the way, it is hard to understand why you need this. And I see now  
> that SQLite lets you define triggers on select statements (but likely  
> these do not allow data manipulation). Regards, Edzard Pasma
>
>   
yes, I realize my use case is a little bit strange. ;) I'm just trying 
to get lazy evaluation for my results, so I do work only if the user is 
actually going to make use of the data. the population step is by far 
the biggest bottleneck, so all of my efforts are on reducing that.

thanx,
ryan