Re: [sqlite] [EXTERNAL] Re: Feature request, sqlite3_stmt_action

[Dominique Devienne]

On Thu, Mar 28, 2019 at 1:35 PM Hick Gunter  wrote:

> IMHO the sqlite3_set_authorizer() interface already does a pretty decent
> job of providing the requested information:
>

True, but only if you are fully in control, because authorizer do not
"stack". There's only one, you can't get to restore one a previous one.
Which is logical since used for "security". But when you want do it both
for security, and introspection, and are you are part of a larger
application using SQLite, it makes things more complicated than it should
be. This was NOT designed for statement introspection after all... --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [EXTERNAL] Re: Feature request, sqlite3_stmt_action

[Hick Gunter]

IMHO the sqlite3_set_authorizer() interface already does a pretty decent job of 
providing the requested information:

asql> explain insert into tx7300.vals(keyid,value,sync_offset)
 ...> select k.id,tx.retailer_loc_id,tx.sync_offset from tx7300.keys k, 
atx_txlog tx where k.name='retailer_loc_id' and tx.period_no = 7300 and 
retailer_loc_id;

2019-03-28 13:27:27.821: AUTH: T: vals C: (null) D: tx7300 A: (null) P: Insert
2019-03-28 13:27:27.821: AUTH: T: (null) C: (null) D: (null) A: (null) P: Select
2019-03-28 13:27:27.821: AUTH: T: keys C: id D: tx7300 A: (null) P: Read
2019-03-28 13:27:27.821: AUTH: T: atx_txlog C: retailer_loc_id D: main A: 
(null) P: Read
2019-03-28 13:27:27.821: AUTH: T: atx_txlog C: sync_offset D: main A: (null) P: 
Read
2019-03-28 13:27:27.821: AUTH: T: keys C: name D: tx7300 A: (null) P: Read
2019-03-28 13:27:27.821: AUTH: T: atx_txlog C: period_no D: main A: (null) P: 
Read
2019-03-28 13:27:27.821: AUTH: T: atx_txlog C: retailer_loc_id D: main A: 
(null) P: Read

-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von Dominique Devienne
Gesendet: Donnerstag, 28. März 2019 11:26
An: SQLite mailing list 
Betreff: [EXTERNAL] Re: [sqlite] Feature request, sqlite3_stmt_action

On Thu, Mar 28, 2019 at 10:59 AM R Smith  wrote:

> Maybe even, if possible, This query updates these tables: x1, x2, x3...
> etc. (some of which might hide behind an FK relation or Trigger)  but
> I know this is pushing my luck.  :)
>

What I ended-up doing is introspecting the VDBE program of the statement.
It's not exactly easy, and can be brittle too, since the output is not 
"publicly documented"
so subject to change w/o notice, but I consider this approach less brittle than 
parsing the SQL.


> Plus, I really do not mind if this explain takes some time, it will be
> faster and more future-proof than any self-parsing one can do.


Right. Some info about the statement from EXPLAIN QUERY PLAN, that DRH would 
agree to, and accept to "publicly document" and thus support would be nice, 
good idea.
No an AST of course, but would go a long way already, for those of us that 
need/wish for that.

I'll put it on my Xmas list :). --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
 Gunter Hick | Software Engineer | Scientific Games International GmbH | 
Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 
1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users