On 29 Jul 2019, at 5:44pm, x wrote:
> It’s not as easy to get access to sqlite3TreeViewSelect on windows as it
> would appear to be in the unix debugger. When I did find out how to access it
> I noticed it returned a string that would enable me to do away with reams of
> code I wrote to do
Thanks Richard. I’ve being doing my best with the code but time is not on my
side. It took me ages just to get the clang compiler to debug sqlite code (had
to split the files).
It’s not as easy to get access to sqlite3TreeViewSelect on windows as it would
appear to be in the unix debugger.
On 7/29/19, Hick Gunter wrote:
> Qquestions about which internal
> representation ... is something only the developers would
> be able to divulge,
The internal representation and the output of sqlite3TreeViewSelect()
are emphatically not APIs. Both are undocumented and both can and do
change
You stated your goals were
a) authorization
b) some unspecified manipulation
I don't see how the order of the information available on the Sqlite authorizer
interface is at all relevant to the result of authorization. Either the set of
necessary operations are all allowed individually (total
I’m still not sure what you’re getting at Gunter. The example code doesn’t
present a problem, it’s when subqueries within subqueries and withs are added
it gets a lot more complex.
I’ve already written c++ code that interprets (more or less) any sql and works
out the schema.table.column each
Let's go back to your example statement with your join of two tables.
select b,c from tbl0 join tbl1 where tbl0.a = tbl1.a and tbl0.a > ?1;
SQLIte should ask the authorizer the following questions:
1) SELECT
2) READ tbl0
3) READ tbl1
4) READ tbl0 field a
5) READ tbl1 field a
6) READ tbl0 field
>>That strikes me as purely procedural thinking. Does the set of allowed
>>operations really depend on the order of the requests (which probably depends
>>on the query plan)? E.g. "you can update this field of this table only if you
>>read this other field from that other table *first*"?
I’m
That strikes me as purely procedural thinking. Does the set of allowed
operations really depend on the order of the requests (which probably depends
on the query plan)? E.g. "you can update this field of this table only if you
read this other field from that other table *first*"?
>>Your implicit claim is "not all instances of column reference are reported to
>>the authorizer, notably those inside a USING clause
That and you’ve got to anticipate the order they’re sent to the callback in.
___
sqlite-users mailing list
Note that parsing debug output is not a stable method of analysis (meaning
SQlite Dev can change anything at whim), whereas the authorizer interface is
documented.
Your implicit claim is "not all instances of column reference are reported to
the authorizer, notably those inside a USING
10 matches
Mail list logo
