TABLE statement to cause the table to (1) allow only a few well-defined
datatypes, (2) rigidly enforce those types, (3) require NOT NULL on PK
columns, (4) always enforce foreign key constraint, and so forth? This
branch seeks to explore that question.
FossilOrigin-Name: 78732b9f98936693ae29c85a692c35a84c7d065aec79903af34b08d18f10a5e6
extension to the column name, for an additional savings in the heap space
needed to hold the schema.
FossilOrigin-Name: 832ac4c1ee384be0de72a4bdd55ed87e0f8294e7df5eefcf6b4942db3d85a69e
to save memory in the common case where the column has no DEFAULT clause.
FossilOrigin-Name: 8646547e54211d44c415663c33775c4268550f8332949c4731a4bb6ec9cc663a
"BLOB") and if a column has one of those datatypes, store the type part of
the bit-field information in the Column structure to save space.
FossilOrigin-Name: d2da62a9df63036b02dadca3798de9e623c2680b3ef0c37d2b18bb88693afd7f
the result in any way. See
[forum:/forumpost/2d76f2bcf65d256a|Forum post 2d76f2bcf65d256a] for
details and history.
FossilOrigin-Name: 85ddaf1b59a19cbd9efe7724a163b30c14bafabfaf2cfced07b463e76f73e494
clauses do not affect the output. See
[forum:/forumpost/2d76f2bcf65d256a|forum thread 2d76f2bcf65d256a] for
discussion. This can help the query flattener in
some cases, resulting in faster query plans. The current implemention does
not always work.
FossilOrigin-Name: ef97c3e7c3ea2cf1a4db6591328fe7ce3f1d189afc2d578159135824ec89e620
in front of ctime.c so that default values that are not overridden are
shown in PRAGMA compile-time option output.
FossilOrigin-Name: e306952690bfb140e2c404a74b05ff2d070c487f7e52c62d62a004505fba0e15
to the number of columns in the vector. This is not strictly necessary. It
just simplifies the state description and make the code easier to reason about.
FossilOrigin-Name: 026f08d4cff19a95e0f38f2ef431cacd65c7c77ed92e30d7f2ded84651f47150
CTE name resolution problem described in
[forum:/forumpost/8590e3f6dc|forum post 8590e3f6dc].
Test cases for both problems added.
FossilOrigin-Name: 5614279daff5007d6e047c5c1b3cc82ba80a5c91c529525b0fe68b79ee82dd2c
default. Omit the SQLITE_ENABLE_DESERIALIZE option and replace it with
the SQLITE_OMIT_DESERIALIZE option.
FossilOrigin-Name: 6df3b03e00b1143be8fed3a39a58ce81063020275aa1ac13d87c84f1ceda6e27
speeds them up depending on the query. And (see
[forum:/forumpost/8692d94725|forum post 8692d94725]) it sometimes results in
an incorrect answer. We may come back and revisit this optimization later,
but for now it seems best just to disable it.
FossilOrigin-Name: 16252d73fa73569fd7506676f6ffbbcd43addfb105384fb74449d30ca720904a
Walker.bWalkWinDefn boolean (which is not always initialized) and uses
a special value for xSelectCallback2 instead.
FossilOrigin-Name: bef2238de9550de84d4cd1c970a542b43db288d73d09a3c3ced7f98bb3188fd3
Do not abandon sqlite3ResolveExprList() on nNcErr if nErr is still zero
as we might have hit a problem with ORDER BY resolution that should be a
suppressed error. dbsqlfuzz 41b9dad40919d3549ca7e52d893da81a6dded4ad
FossilOrigin-Name: 7d674970741bd9b228b818c701c1ae010b90cc287a4c60a872f18b66353d164d
in the sqlite3ExprAnd() routine until the corresponding Parse object is
deleted. This avoids a dangling pointer in AggInfo if sqlite3ExprAnd()
is invoked by the push-down optimization. The dangling pointer appears
to be harmless in release builds, only showing up in debug builds.
Problem found by dbsqlfuzz.
FossilOrigin-Name: c36b43589abd9f62a709bdb47b8748e0c1e8743487a3d83d1eb35eb06b65d763
opcodes, allowing them to run faster. This required refactoring the
vector comparison logic, which in turn required changing OP_ElseNotEq into
OP_ElseEq.
FossilOrigin-Name: 380b46054b6a9b67e57357815e8e94057253fa3cce838ae76e5d5031c6bd26b2
using an ephermeral table to test for duplicates if the column that is
distinct is part of an index.
FossilOrigin-Name: ef4ac0ddd297bbd38351410c5a387e1628561b3f1bec9e4c2c9d76fbe29f955a
