recent addition of support for index expressions on aggregate queries.
[forum:/forumpost/bad532820c|Forum post bad532820c].
FossilOrigin-Name: c34fd9fe1b76e0a5943f014f46141cbe55d41bb1e6980adf9bcb6785a03e7883
New assert() statements added to help verify that memory allocation is
correct, and to help fuzzer find lingering errors.
FossilOrigin-Name: 6f8b97f31a4c8552312b4c98432ea356ae54c06d9cc929969f50c3c88360cd7b
and the left table employs an index on expressions, then make sure the
expressions evaluate to NULL for the cases where the left table should be
NULL. Proposed fix for [forum:/forumpost/9b491e1deb|forum post 9b491e1deb].
More testing an analysis needed - there is a FIXME in this check-in.
FossilOrigin-Name: 3572b40a7dfc4acc35e72e08e79f64688f8737e57ac89e4d10e6b32bd5178c63
register, always use the sqlite3ExprCode() routine because it has the smarts
to know whether to use OP_Copy or OP_SCopy. Do not try to OP_SCopy inline
because an OP_Copy might be required. Fix for the problem identified by
[forum:/forumpost/5522082cfc|forum post 5522082cfc].
FossilOrigin-Name: c104e5c6eeb89575319d9f94f49446142b06912fa8b283c19d46aa2ccddc5bda
sqlite3_error_offset() returns. Second of two defenses against
[33aa4c0de8a62e33].
FossilOrigin-Name: 2adb4e0dda471ffc9b2a5cbad01b6c2bc6091b7526a8c8b19944cb2d4a5111e7
[forum:/forumpost/2e427099d5|forum post 2e427099d5] and
[forum:/forumpost/d47a0e8e3a|forum post d47a0e8e3a].
FossilOrigin-Name: c028fb669a5ae34dbaf50fffab1ae49bc568b994435cf02e145d24da3cfb48d7
has the wrong affinity. dbsqlfuzz 65f5eb57f8859344d5f1f33e08c77ee12960ed83
FossilOrigin-Name: e95439119ac200cb47d0e277622f41ee7986b364487cd252b485ce5fa030d70f
(check-in [41c27bc0ff1d3135]), ensure that the OP_IfNullRow opcode does not
NULL-out a subquery result that was computed within OP_Once. This fixes
the problem problem reported by
[forum:/forumpost/402f05296d|forum post 402f05296d].
FossilOrigin-Name: 8fe13f7a5e5eb798189acb25a608df7a94c2f5cc83463331a048b779c7890c82
boundary even if the function that returned the value with a subtype is
buried down inside a larger expression. This fixes a problem identified
by [forum:/forumpost/37dd14a538|forum post 37dd14a538].
FossilOrigin-Name: e72661eb680ea707a839cb3d5cf6c7ef03706e7b40af1b84760147e59cd61a50
be added to the output of the affinity() built-in function.
dbsqlfuzz d309eaa5fe492c9606a8be876c2bc7dedb29d3d8
FossilOrigin-Name: f4ec68ceefa3a607f37d6355aac89fd1ae1704da4061bad7f271db1f17c1dd3a
RIGHT JOIN as that leads to problems, as shown by
dbsqlfuzz a644e70d7683a7ca59c71861a153c1dccf8850b9.
FossilOrigin-Name: f113eebdbe68246fd38d640b0cdf0fd73ab5d2abad9226274dfa2e41fe286bf0
never tries to convert integer to real or real to integer. The affinity is
only used internally - it is not possible to create a table column with this
affinity. This affinity is used on subqueries and views that are built off
of a compound SELECT and where the datatype is controlled by a CAST expression.
dbsqlfuzz c9ee6f9a0a8b8fefb02cf69de2a8b67ca39525c8
FossilOrigin-Name: 44135d6ea84f7ba6b36549954b38a8bc048d5ffea5a9779e35950afa4eb2dfb2
a compound with different result datatypes on two or more arms of the compound,
then the overall column type becomes BLOB (ANY).
FossilOrigin-Name: 6ebb178c6b688ebd632e91a5ec4c748567833037c679ab3d72fb770deb230fe1
not have an associated Table object because it is a reference to an indexed
expression.
FossilOrigin-Name: 5fc23863e4a6388884ce061cd69546757b4c39d731bbb58a8121b92fd5144f7b
works and gets the correct answer for the test case in the ticket. Lots more
testing and documentation is needed, however.
FossilOrigin-Name: 8dcf9f2031c16f296d187fe876d4204c71fc96fec120984ff11b6d8b03d58a5f
work. It gets an incorrect answer for the test case shown in the ticket.
FossilOrigin-Name: 84c06023f4a1606664fdb9811312603b31f7c94a43d0e443ba7dde7fdba029e3
AggInfo object are sequential, it is not neecessary to remember each register
separately. We can simply remember the first one and do the math when
others are needed.
FossilOrigin-Name: dc5bd34963b761c819c565653156d0befbf65cc2cc5dc4113b0ce952450f0352
distinct from all other identifiers in the code and thus less confusing.
FossilOrigin-Name: a2962d0187534f3496282b48efbf38dabcd226bf8972be925c8433c55a8853fe
the prior [a47efb7c8520a011] enhancement from 2017 obsolete. This check-in
removes the older optimization.
FossilOrigin-Name: 56442c9bdd7844454c79acf83323380ea3509cb2e0b9a3d538a6b51726ae6d07
in place of the expression that is being indexed. This particular check-in
mostly works, but there are still issues.
FossilOrigin-Name: 2e8d4fd4cfd9e82f33c707ba246fe2bb3ca01762cf5ac5905058fbc7adf0abe7
loading the entire content of larges strings and BLOBs. Response to
[forum:/info/3c08d4715dc05b00|forum post 3c08d4715dc05b00].
FossilOrigin-Name: 45f171565442f9fd6574fb93ae7abe83c168b20be68af42531bc55571450d3ab
EP_OuterON constraints on the same FROM clause term) really necessary? This
branch explores what happens if we omit that restriction. This is an effort
to address the performance regression reported by
[forum:/forumpost/96b9e5709cf47cda|forum post 96b9e5709cf47cda] that is caused
by flattener restriction 29.
FossilOrigin-Name: 19270577ad1d08c9e6e5f0600396b8a1ccda9df1e67a0df845aee6b60437f379
db and ptr parameters are guaranteed to be non-NULL. Use this where
appropriate to save more than 2 million CPU cycles on the standard
performance test.
FossilOrigin-Name: e5eaa80e81fdf86f2875a912b880272b8d099b82b08e945a7988c5dd0fe9d6b5
drh