Re: [sqlite] SQLite version 3.28.0 beta 1

[siscia]

I would really support this other approach.

It seems more extensible and eventually would address on of my pain points
in SQLite, not knowing what type of statement is being executed.



--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.28.0 beta 1

[Simon Slavin]

Rather than  sqlite3_stmt_isexplain(S)  would it be possible to define a  
sqlite3_stmt_type(S)  function instead ?  This would return integers equivalent 
to

SQLITE_STMT_ERROR = -1
SQLITE_STMT_OTHER = 0
SQLITE_STMT_EXPLAIN = 1

and in future other values as they become useful ?  You could add easy ways to 
identify PRAGMAs, SELECT, INSERT, etc. as needed in future.  Until these are 
added, everything but EXPLAIN evaluates as SQLITE_STMT_OTHER, unless the 
function cannot identify the statement type in which case you get 
SQLITE_STMT_ERROR.

An alternative set of codes which might be preferred are those already in use 
as authorizer action codes:



Extend these by adding SQLITE_EXPLAIN (or SQLITE_EXPLAIN and 
SQLITE_EXPLAIN_QUERY_PLAN), and use these codes instead of starting a new set 
of codes.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users