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. 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 the same thing. I’m finding it hard to let go now. ☹
With a bit of extra code I’ve managed to get the result of the
sqlite3TreeViewSelect sent to the authorizer callback a line at a time. How I
would’ve loved a sqlite3_TreeView_sql(stmt) function although having messed
about with the code I appreciate how difficult that would be.
________________________________
From: sqlite-users <sqlite-users-boun...@mailinglists.sqlite.org> on behalf of
Richard Hipp <d...@sqlite.org>
Sent: Monday, July 29, 2019 4:54:36 PM
To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] [EXTERNAL] Help with sqlite3TreeViewSelect
On 7/29/19, Hick Gunter <h...@scigames.at> 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 from one release to the next. The sqlite3TreeViewSelect()
interface is intended for debugging use only.
If you want to know what the output of sqlite3TreeViewSelect() means,
you should consult the source code in the treeview.c source file for
the specific version of SQLite you are running. That's what the
developers do. The meanings of the fields in the internal
representation are well described by code comments, especially in the
sqliteInt.h file. For information about specific fields or values,
try grepping in the source code. There are usually nearby comments
that explain what is going on.
Sadly, the IF_NULL_ROW value is not as well commented as it might be.
But, by looking at the source code, you quickly get the idea that it
has something to do with LEFT JOIN. And if you search the Fossil
repository history, you can see that the identifier was added here:
https://www.sqlite.org/src/timeline?c=3a5860d86fadcf92
Using those clues, perhaps you can figure it out. I added the
IF_NULL_ROW code myself but that was over two years ago and at this
point I don't remember exactly why. I'll have to go back and reverse
engineer it, if and when I improve the comments, or should we ever
need to work on that particular aspect of the implementation.
As with all of the internal representation, we might find a better way
to accomplish the same thing tomorrow, and totally eliminate the
IF_NULL_ROW operator from the code. So don't become too attached to
it.
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
