DISTINCT and contains an OFFSET clause.
[forum:/forumpost/2025-12-03T09:25:59Z|Forum post 2025-12-03T09:25:59Z].
FossilOrigin-Name: aef5397569d65d2971367b0278fe3a6f42544cf771572e7d046e2472f052364d
name resolution, scan the WHERE clause to verify that the ON clause does not
reference tables to its right.
FossilOrigin-Name: 0ec8a8f64434f8cc04f02a356ecaa409ebd886566ba09c32f0fff8ebd103a609
the subquery contains a LIMIT clause.
[forum:/forumpost/2025-07-23T10:59:14z|forum post 2025-07-23T10:59:14z].
FossilOrigin-Name: 314c493f273a34dff7b9f954e7553bc540bbcf5b913f779ef9ce0b9ba11acf7a
even when the aggregate is on the right side of a LEFT JOIN and never
gets evaluated. This fixes a problem introduced by [663f5dd32d9db832]
and found by dbsqlfuzz. Test cases in TH3.
FossilOrigin-Name: 235cf6586b9ac914a32bd8adfd460daae998687f02f0998a7aa3c6bfc857d1c9
that do not have a WHERE clause, and so that it works on nested EXISTS
subqueries.
FossilOrigin-Name: c1d5295724f9cf7f49e0786d28016eff2d268a2b670f934d24c76787626089db
This problem was discovered overnight by
[https://github.com/google/oss-fuzz|OSSFuzz].
FossilOrigin-Name: 6db4703f1178fc808f3a75c355fb6638fb12c88f6e1ce7f579e200ced8089114
NATURAL JOINs to the left of RIGHT JOINs where source tables are views
or subqueries. Initial problem report in
[forum:/forumpost/829306db47|forum post 829306db47].
FossilOrigin-Name: f184d1d236e47962658a4639d9533f67a525b74cfe0f06c93e9b85fdcd02a15f
a LEFT JOIN even if the RHS contains a virtual table. This was previously
disallowed by [9dbae1df75219e2a] as a performance optimization. It
turns out that the constraint causes performance issues, and we do not have
a record of any performance issue that it solves.
FossilOrigin-Name: 1ddaa92057e550ea281d45d9860eafe69399224725548a93dd91c47a34e52152
side is coming from a RIGHT JOIN, be sure to set the EP_CanBeNull flag so that
the optimizer knows to check for NULL even if the column has a NOT NULL
constraint. Fix for the problem reported by
[forum:/forumpost/4fc70203b61c7e12|forum post 4fc70203b61]
FossilOrigin-Name: 60adc78a22956429d34ccc4e2c193c5994c11c3b3cff7901d47fad7d92dba935
duplicate compuations in the GROUP BY clause so that it works even if the
GROUP BY term is a subquery on the RHS of a LEFT JOIN. Problem found
by dbsqlfuzz. Test cases in TH3.
FossilOrigin-Name: 955a026996b93e530ca5b566689cc646b31d3b9b5a5837897a58452d70f6d942
that uses the UNION operator. Follow-up to [f911f1c4977fbcae] and it's output row
estimate changes associated with DISTINCT queries.
FossilOrigin-Name: 92513f6bce7ecc778e78af3a77bc66ff65585fffa2e3138f8acb9e617121eeb0
pacify -fsanitize=strict-bounds. This check-in fixes the core. There is
more yet to do in FTS3, RTREE, and in FTS5.
FossilOrigin-Name: 6fd6b32d06bd6a705e5140cd613af823b8183a6f6a9ceeeedfcf5e8b50821d68
is DISTINCT, as the optimization does not work in that case.
Bug reported by [forum/forumpost/a860f5fb2e|forum post a860f5fb2e].
FossilOrigin-Name: d7013b63932b2f5750572ae6bdd259a2b6e6548c20fb9a5559edd22d2f2fc6cb
to use more than SQLITE_LIMIT_COLUMN columns and raise an error.
Also include some unrelated compiler warning fixes.
FossilOrigin-Name: d7729dbbf231d57cbcaaa5004d0a9c4957f112dd6520052995b232aa521c0ca3
capability to increase it further up to 32767 using a compile-time option.
FossilOrigin-Name: e8d7d68ba0bb0bc2f948db5d9966990a5d23597fc3658b7cd0bc99d53c7353a9
