(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
expressions in an aggregate query. Proposed fix for the problem identifyed by
dbsqlfuzz 8e17857db2c5a9294c975123ac807156a6559f13.
FossilOrigin-Name: 40d08807209638aad728be2cedbc904e342e76c8e486c364bd571b55dd2e1e87
sqlite3ExprDeferredDelete(). This is a better solution than check-in
[c538d07535092722].
FossilOrigin-Name: 2a6f6971fa010219323b976ff53b2606e39fb43fd36c394837c3a8528bf3c425
BLOB literal if there has been a prior OOM.
dbsqlfuzz 23871e5805d6c45b392f9b7aa1e8a2b98f3c27cd.
FossilOrigin-Name: c538d075350927222ab0a6598b844f7b15153c5dc008d71b921a2b73c4f4a7a4
Proposed fix for the problem reported by
[forum:/forumpost/3d9caa45cbe38c78|forum post 3d9caa45cbe38c78].
Additional works is needed as not all cases are covered.
FossilOrigin-Name: 08af1fe27ebd0edf6e0f1ac477deea033e7f7c813f1016b75196836daf02d2e4
thereby avoiding special case code and freeing up a bit in the
FuncDef.flags field.
FossilOrigin-Name: 1c9812c458bd229c862efe5df1b64fae333da9871c8756b5ae4605a81bcda4b5
reuse the same ephemeral cursor of a list subquery when that subquery is
reused, as it does not work in cases where the list subquery is used both
for lookups and for scans.
FossilOrigin-Name: 12ee29d632ae4b585ef6bc07d3289d00c121268945dffd5673b251d95874e3f8
