[forum:/forumpost/5bbabfb7ce|forum post 5bbabfb7ce]. Also use this
opportunity to improve the isSimpleCount() function with better formatting,
an expanded header comment, and some extra assert() and textcase() macros.
FossilOrigin-Name: 2927185be81a5aa0dce70dd06040d05c2816a4d18b5094a6f709732cfd6968dc
its datatype. Fix for the problem reported by
[forum:/forumpost/e5c76b738e|forum post e5c76b738e]. Test cases
in TH3.
FossilOrigin-Name: c7f0813cabf9d8ab367bead5ba8cf20132b8bb9274d8e47b76ad66a10517dd2a
end of code generation, in order to avoid deleting expressions out from under
the aggregation function sanity checking assert()s that occur near the
end of SELECT code generation. This fixes the assertion fault described by
[forum:/forumpost/cfcb4b461d|forum post cfcb4b461d].
FossilOrigin-Name: 600f1991e5c0a5d89cd8776a157b6fd72c7489791085876925e8dd7ab146fe1f
reused in other contexts in where the same optimization is unlikely to
be valid. Fix for the bug reported by
[forum:/forumpost/d496c3d29bc93736|forum post d496c3d29bc93736].
FossilOrigin-Name: a7ce29a6ef2e0362bbc9b23719d936dce07209b2651153c774682f599bbd888e
extension to the column name, for an additional savings in the heap space
needed to hold the schema.
FossilOrigin-Name: 832ac4c1ee384be0de72a4bdd55ed87e0f8294e7df5eefcf6b4942db3d85a69e
when operating on vector assignments of an UPDATE FROM.
dbsqlfuzz 417d2b053b9b3c9edaf22dd515564f06999e029c
FossilOrigin-Name: 60695359dc5d3bcba68a68e1842c40f4a01650eb5af408e02fb856fd8245e16d
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
deal with unusual affinities. See
[forum:/forumpost/6a06202608|forum post 6a06202608] for more detail.
FossilOrigin-Name: 9be208a6d70582c6808abe6e016ab9cd8d10f0deefb8c7a8c0543372cca15b12
than once, as transformations that apply during the first pass might
cause problems for the second pass.
dbsqlfuzz 836b625cd8a41809ef80fc7ebaa6554357bcb463.
FossilOrigin-Name: f30fb19ff763a7cbe768ea49954704e14d6400f69bb4257c9c890e1564e14835
continue since the parse tree may have been left in a goofy state which could
cause use-after-free and segfaults.
See [forum:/forumpost/aa4a7a3980|forum post aa4a7a3980] for an example.
FossilOrigin-Name: 94225d693932eb0b5d7799d40513afbd31ed40e1e156675eb92ad7216f1ff20f
CTE name resolution problem described in
[forum:/forumpost/8590e3f6dc|forum post 8590e3f6dc].
Test cases for both problems added.
FossilOrigin-Name: 5614279daff5007d6e047c5c1b3cc82ba80a5c91c529525b0fe68b79ee82dd2c
generated twice. But for some subqueries, generating code off of the same
tree twice causes problems. So now MULTI-INDEX OR makes a copy of the
sub-expressions it uses to avoid code-generating them more than once.
dbsqlfuzz 9ebd2140e7206ff724e665f172faea28af801635.
FossilOrigin-Name: 4a55f72542c8bcc80253aa77043314cecb29d73cb4f51aa80f7811e86cc8ef68
WHERE clause that has a top-level AND operator, even if the query is not
a join. This is an attempt to partially address the concern raised in
[forum:/forumpost/830d37b928|forum post 830d37b928].
FossilOrigin-Name: e994c9f29f7a561dd5f30573865b0f793fb1388af09a2afb9b1a5b037ea52f89
works better with recursive CTEs.
dbsqlfuzz 88ed5c66789fced139d148aed823cba7c0926dd7
FossilOrigin-Name: f80d7bb2c305c1dd4658767660b33259032c048a91f18c654a6bda7332c54a0c
to OOM. This in turn requires several new NEVER() and ALWAYS() macros for
unreachable branches.
FossilOrigin-Name: a61c0e6b78bd39f55464fafd257e68effded64995a66e8fa2d686e8c507ebe43
This prevents problems in higher-level routines that might not check for
the OOM after processing a subquery.
dbsqlfuzz fb70fa8602421f87673e0670b0712ff2b5240ea0
FossilOrigin-Name: d564d8882ef18b55ebf93e838426b485281c7ebe3a9b321a2f984ed0f229cc25
