Most pragmas allow you to issue them in a mode such as to query a current state.

So to use your example
pragma journal_mode = persist;

followed by
pragma journal_mode;

with a subsequent check to see that the returned value is set to what
you want it to be set to (actually the new value is returned when
journal_mode is set).

Likewise you can use pragma secure_delete to either set or query the
secure_delete mode




Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
-Forensic Toolkit for SQLite
email from a work address for a fully functional demo licence


On 23 November 2016 at 16:36, Scott Hess <sh...@google.com> wrote:
> On Tue, Nov 22, 2016 at 10:50 PM, R Smith <rsm...@rsweb.co.za> wrote:
>> On 2016/11/23 2:08 AM, Scott Hess wrote:
>>> https://www.sqlite.org/pragma.html has:
>>> "No error messages are generated if an unknown pragma is issued.
>>> Unknown pragmas are simply ignored. This means if there is a typo in a
>>> pragma statement the library does not inform the user of the fact."
>>>
>>> I just lost some time due to this, even though I was fully aware of
>>> it.  My code wasn't working, so I instrumented to report errors, and
>>> gradually dug things deeper and deeper.  It wasn't until I was
>>> verifying statements line-by-line against sqlite3 in a terminal window
>>> that I saw that I was setting journal_mod rather than journal_mode!
>>>
>>> I realize that pragma don't have the compatibility guarantees that
>>> other syntax has.  But that means I actually _would_ want my code to
>>> start barfing if a PRAGMA stops being supported.  Say I'm issuing
>>> "PRAGMA secure_delete=ON" - presumably it's for a reason, and I'm
>>> going to want to revisit that reason if it's no longer supported.
>>
>> The problem is more the other way round - Backward compatibility is hard
>> when you introduce a new pragma, and a previous version of SQLite "barfs"
>> suddenly when it encounters that statement. Recent posts here re-emphasize
>> the frequency with which old versions are still used out there....
>>
>> Silently ignoring an unrecognized pragma is a great way to be able to
>> introduce new functionality without worrying that the old will break.
>
> I may be misunderstanding where you're going with that, but my point
> was that there are some situations where I'm calling a PRAGMA because
> it's important to some implementation detail.  For instance, if your
> app's schema requires operational foreign keys, then simply ignoring
> "PRAGMA foreign_keys = ON" is _not_ kosher (I mean, yes, there's
> nothing SQLite can do to fix being old or compiled that way, but
> signalling "I can't do that, Dave" would be helpful).  How the PRAGMA
> I am _not_ calling are handled doesn't seem super relevant to that
> case, because I'm not calling them.
>
> Of course, my "PRAGMA pedantic_pragma = ON" call would itself succeed
> by failing on an older version of SQLite.  You have to bootstrap
> someplace, so you'd have to make the call to turn it on, then do
> another query to verify that it is on.  Which I guess is basically
> what your PRAGMA should already be doing, though there are subtleties
> (PRAGMA result patterns aren't consistent across different PRAGMA).
>
> -scott
> _______________________________________________
> 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

Reply via email to