Pragma compile_options does not show some options
(1) By anonymous on 2021-04-12 22:47:43 [link]
I compile SQLITE amalgamation with some compile-time options and query db later with "pragma compile_options". Two compile options are missing : SQLITE_DQS=0 SQLITE_DEFAULT_MEMSTATUS=0 Are these options not supported on amalgamation build?
(2) By Larry Brasfield (larrybr) on 2021-04-12 23:44:55 in reply to 1 [link]
If SQLITE_DEFAULT_MEMSTATUS has been #define'd as non-zero, "DEFAULT_MEMSTATUS" appears in the pragma compile_options output. The SQLITE_DQS compile option does not appear in that pragma output, regardless of its value or whether it is #define'd at all. The options are supported in the amalgamation.
(3) By anonymous on 2021-04-13 18:11:16 in reply to 2 [link]
(4) By anonymous on 2021-04-13 18:34:51 in reply to 2 [link]
>The SQLITE_DQS compile option does not appear in that pragma output, regardless of its value or whether it is #define'd at all. Is there a specific reason *why* this option is not included? Could it be included in the next version?
(5) By Larry Brasfield (larrybr) on 2021-04-13 18:51:02 in reply to 4 [link]
I cannot state the causality. But I can see a reasonable rationale which is why I elected to not treat this omission as a bug. Most (if not all) of the compile options which appear in "pragma compile_options" relate to capabilities and capacities. The two bits encoded into SQLITE_DQS are different in that they specify a pair of deviations from standard SQL syntax rules which are to be allowed or disallowed. Neither affects how correctly written SQL is compiled or how such SQL will perform. They therefore have have less utility for applications which may need to ensure a feature is present or a capacity suffices. If there is a good case for its inclusion in that pragma's output, this would be a good place to present it.
(6) By Keith Medcalf (kmedcalf) on 2021-04-13 18:58:29 in reply to 5
You will also note that ctime.c only outputs define status declared either on the compiler command line or the config.h file and does not reflect the as-built configuration. That is, it is generated *before* the configuration is processed, not after (before all the .h files are processed, not after).
(7) By anonymous on 2021-04-13 19:48:50 in reply to 5 [link]
Is *SQLITE_DQS* really that different? Just as a compile option *ENABLE_JSON1* shows that JSON parsing is enabled or disabled and therefore a SQL statement containing JSON fuctions can be processed or not, *SQLITE_DQS* shows what combinations of abuse of double quotes will be accepted or rejected. A statement like ``Select "Hello"; `` which is processed with *SQLITE_DQS=3* results in an error with *SQLITE_DQS=0*.
(8) By Gonzalo Diethelm (gonzus) on 2021-04-14 14:10:08 in reply to 1 [link]
I came here to report that when compiling with `SQLITE_ENABLE_DESERIALIZE` set to 1, this option also does not show up in the output of `pragma compile_options`.
(9) By Keith Medcalf (kmedcalf) on 2021-04-14 18:03:41 in reply to 8 [link]
There are quite a lot of definitions missing from tool/mkctimec.tcl (the TCL script which generates the piece of ctime.c that defines the output of the pragma compile_options).
(10) By Larry Brasfield (larrybr) on 2021-04-14 18:32:04 in reply to 8 [link]
Thanks for your report. That option and several others will soon appear in that output.
(11) By Gonzalo Diethelm (gonzus) on 2021-04-14 19:23:57 in reply to 10 [link]
Lovely, thanks for the quick reaction!
(12) By Larry Brasfield (larrybr) on 2021-04-15 01:12:54 in reply to 6 [link]
I've just taken a look at this issue (order of ctime.c content w.r.t. config.h content), and do not see any actual conflict or overriding of options detected one way for compile_options output and then changed to yield a different conditional compilation. This was worth a review, (so I am not complaining!), but do you have a specific problem in mind? Or is this a general principles kind of concern?
(13) By Keith Medcalf (kmedcalf) on 2021-04-15 01:39:42 in reply to 12 [link]
Just an observation. There are many defaults that are set at various places various header and source files but are not reflected in the output from compile_options. For example, the default for the define SQLITE_DEFAULT_MEMSTATUS is 1 and that default is set long after ctime.c has been processed in the amalgamation. This means that the output of pragma compile_options reflects compile settings and not the as-built settings (that is, if DEFAULT_MEMSTATUS does not appear in the pragma compile_list then the code was compiled either with that option actively disabled *or* perhaps it is enabled by default -- it appears in the pragma output only if it was specifically enabled.)
(14) By Larry Brasfield (larrybr) on 2021-04-15 01:54:37 in reply to 13 [link]
I'll have to look at this again; I misunderstood your point and concentrated on included headers (or pseudo-included in the amalgamation). I certainly agree that there appears to be a hazard where defaults are effected later in the compilation than where the options are examined for that pragma output. This may require a revised approach to option capture, or relocating that processing. More later.
(15) By Gonzalo Diethelm (gonzus) on 2021-04-15 10:02:50 in reply to 11 [link]
BTW, this also affects [what's returned from `sqlite3_compileoption_used` and `sqlite3_compileoption_get`](https://www.sqlite.org/capi3ref.html#sqlite3_compileoption_get). While this may be obvious, it presents the additional problem of it being impossible to check at runtime whether the library was compiled with support for `SQLITE_ENABLE_DESERIALIZE` (and any other option currently missing).
(16) By Larry Brasfield (larrybr) on 2021-04-15 10:11:35 in reply to 15 [link]
The changes to remedy this are done, awaiting completion of pre-checkin testing to be committed non-locally. At this point, additional persuasive effort will have little effect. I agree that the build option exposure should work correctly and reflect those options which impact normal use of the library.
(17) By Gonzalo Diethelm (gonzus) on 2021-04-15 11:12:01 in reply to 16 [link]
> At this point, additional persuasive effort will have little effect. :-) I wasn't trying to persuade anybody, I was just bringing this up because I wanted to make sure the solution to the first problem also solves this additional problem (which, I would think, is highly likely). Thanks for all the changes!
(18) By skywalk on 2021-04-15 14:28:19 in reply to 16 [link]
Yaaay! I stumbled on this before when debugging external tools using precompiled sqlite binaries. For clarity, are all options runtime tracked or we must continue to report missing pragma and compiler options?
(19) By Larry Brasfield (larrybr) on 2021-04-15 14:43:57 in reply to 18 [link]
Options affecting significant features and non-defaulted capacities will all be exposed soon. It would be duplicative effort to sift through the current set of potentially exposed options for comparison with documented options. Features supporting internal testing, (often undocumented), and arcane backwards compatibility options that affect only poor SQL usage, will remain unexposed. Also, only options affecting the SQLite library itself are exposed; options affecting the CLI shell are not.
(20.1) By Larry Brasfield (larrybr) on 2021-04-18 14:17:48 edited from 20.0 in reply to 13 [link]
Just following up on this perceived hazard: I examined all #define's following the option detection which could alter an exposed option's effectivity to differ from the pragma compile_options output. (Some text processing and a DB join made this a non-onerous task.) I found <s>10 </s><i>5 truly</i> in that category. This will be fixed. Thanks for the heads-up on this issue.
(21) By Larry Brasfield (larrybr) on 2021-04-18 16:25:41 in reply to 7 [link]
> Is SQLITE_DQS really that different? Yes. It's just as different as I said. Exposing it in pragma compile_options would have this benefit: Somebody who wonders, "Can I be sloppy with SQL literal and identifier quotation?" will have a slightly more conveniently gained answer than trying some malformed SQL. As I see it, those who know enough to understand what malformed SQL is **and** to use "pragma compile_options" will also have low motivation to write malformed SQL. Hence the convenience is hypothetical and the utility (in practice, counted over all users) is low.