code, but it is needed to prevent nuisance "stack overflow" reports from
OSSFuzz while it is running the latest ASAN.
FossilOrigin-Name: 70abc144ca90a58ea25dc2d90683545246c084d961215c20ec070b0abe640371
arguments are SQL functions that are able to return subtypes. This closes
a corner-case hole in the patch at [ba789a7804ab96d8].
FossilOrigin-Name: b36d499e4cdb41a5d7e44a1c4347a059d7654f85ade9c5c04d18ac95ddc09fde
marked with SQLITE_RESULT_SUBTYPE, or (2) one of its arguments is a function
that is able to return a subtype. This check-in backs out the code changes
from the previous two on this same branch, but keeps the test cases from
the previous two.
FossilOrigin-Name: f16b200f25a0ec59ad765d254d81c3ffdba21f79e6e82807a7b80d00627952e2
also be marked as SQLITE_RESULT_SUBTYPE, in case one of their arguments has
a subtype.
FossilOrigin-Name: 2f9fba931d9f80b3d5dffb175180098756bccc6a8f665d7aaf8826970ab60d72
from their arguments, and hence need to have the SQLITE_RESULT_SUBTYPE flag
set. This fixes an corner-case for the patch at [ba789a7804ab96d8].
FossilOrigin-Name: cdd1610c44876623e629bb8e5779ea689e6d23c545552b088eca63ad2d1cf8da
[forum:/forumpost/4cf69794d9dfff7c|forum thread 4cf69794d9dfff7c] in two
different ways: (1) Omit the call to PRAGMA integrity_check('X') that was
being done after CREATE TABLE "X" because the result was being ignored and
the integrity_check was not doing anything other than burning CPU cycles.
(2) Do not interpret the argument to PRAGMA integrity_check as a number if it
is in fact a string that looks like a number.
FossilOrigin-Name: 71f08b912251c8a3ac1bd8e344903336648e4187f7493f8c126e60b3b51b9f09
PRAGMA integrity_check as a number. Treat it as a table name that just
happens to look like a number.
FossilOrigin-Name: b04e7a23478f1012e501a810f3e09cca81a66e802f5f72cae80c81120174e2cb
because it is a no-op. Even if the integrity_check failes, the CREATE TABLE
is stull successful. The OP_SqlExec just burns CPU cycles for no reason.
FossilOrigin-Name: 532795acd1c800751737fe70148f9ae691e9cf11b836577f8538421d24cab2fe
The first problem was reported by
[forum:/forumpost/c243b8f856|forum post c243b8f856]. That report prompted
an enhancement to the generate_series() (also included in this merge) which
in turn identified other similar issues.
FossilOrigin-Name: 5f6c079d847e3664ec5acaf1b3e989efe0d548c211ae4a18936162b36df89065
LIMIT and OFFSET. Use this to add new test cases for LIMIT and OFFSET
on virtual tables in a compound SELECT.
FossilOrigin-Name: 408d47ecaa3b906d0886f76a22b76339ec5878270ffe8d1838c74de09c29a33e
compound subquery. The affinity is the affinity of the left-most
arm of the compound subquery that has an affinity other than NONE, adjusted
to accommodate the data types coming out of the other arms.
FossilOrigin-Name: e6df846f36209bac3e420dd80ce2bbbd87ab7a20b8063fce05f78a3c7ab6027e
make sure that the selected affinity is compatible with a literal values in
arms to the left of the arm that is used to determine affinity.
FossilOrigin-Name: bbdf22e3d989f42b963f1f2f219dfeac11db786f17ac27097ab72f72e7638a2a
affinity of a subquery by the left-most arm of the subquery that has an
affinity other than NONE. In other words, scan from left to right looking
for an arm of the compound subquery with an affinity of BLOB, TEXT, INTEGER,
or REAL and pick the first one found. Or stay with NONE if no arm has a
defined affinity. Test cases added.
FossilOrigin-Name: b8ec8511b1968bbc1472b3e2e21f0fef1d5becebeb31f9d13ee3ca9e13abb1e5
being updated in the statement that includes the RETURNING clause, then mark
the subquery as correlated sot hat it is recomputed for each result and not
just computed once and reused. See
[forum:/forumpost/2c83569ce8945d39|forum post 2c83569ce8945d39].
FossilOrigin-Name: 9ea6bcc8fdf6aadb756ec5bcaaa7af314167f8973bdd32fd23f83bd964f0c21e
stephan