database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-11-12 13:01:09 +03:00
Code Activity

Turn restriction 20 on the query flattener into an assert since the situation

Browse Source 
restricted can no longer occur because of the more aggressive use of
co-routines.

FossilOrigin-Name: 4464f40ccd7c5553f4d44120ca6dac4e9445f08f083f7dcb3bd66b4413d818e0
This commit is contained in:
drh
2017-10-04 12:06:31 +00:00
parent 61b513e9e3
commit 7c58fea39f
3 changed files with 23 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
manifest
View File

@@ -1,5 +1,5 @@
C Add\stests\sto\sverify\sthat\sthe\sbusy-handler\sis\sinvoked\scorrectly\swhen\sprocessing\s"PRAGMA\soptimize"\sand\sANALYZE\scommands.
D 2017-10-04T10:39:28.853
C Turn\srestriction\s20\son\sthe\squery\sflattener\sinto\san\sassert\ssince\sthe\ssituation\nrestricted\scan\sno\slonger\soccur\sbecause\sof\sthe\smore\saggressive\suse\sof\nco-routines.
D 2017-10-04T12:06:31.705
F Makefile.in 4bc36d913c2e3e2d326d588d72f618ac9788b2fd4b7efda61102611a6495c3ff
F Makefile.linux-gcc 7bc79876b875010e8c8f9502eb935ca92aa3c434
F Makefile.msc 6033b51b6aea702ea059f6ab2d47b1d3cef648695f787247dd4fb395fe60673f
@@ -458,7 +458,7 @@ F src/printf.c 40aee47ae9be4bd3dbdc8968bd07fddc027be8edec8daddf24d3391d36698a1c
F src/random.c 80f5d666f23feb3e6665a6ce04c7197212a88384
F src/resolve.c 4324a94573b1e29286f8121e4881db59eaedc014afeb274c8d3e07ed282e0e20
F src/rowset.c 7b7e7e479212e65b723bf40128c7b36dc5afdfac
F src/select.c 8a506e0a27799e96276aea0b5fd1591762905bd572f326d2886cb74f5ceb5f4a
F src/select.c 42aca61e739c405ddd8a1b702977a7743c7d52a94885f7c5596bd7e73e6bff18
F src/shell.c c1206a23d9239f8f51751d3be9b8c3b02fa4103546bea1add7f864d84a8276ab
F src/shell.c.in bb9720a8c5c98d3984b16ab7540e7142bcae959666ecf248bfc523a1d44220ee
F src/sqlite.h.in ab4f8a29d1580dfaeb6891fa1b83cff8229ba0daa56994707ceaca71495d9ab7
@@ -1655,7 +1655,7 @@ F vsixtest/vsixtest.tcl 6a9a6ab600c25a91a7acc6293828957a386a8a93
F vsixtest/vsixtest.vcxproj.data 2ed517e100c66dc455b492e1a33350c1b20fbcdc
F vsixtest/vsixtest.vcxproj.filters 37e51ffedcdb064aad6ff33b6148725226cd608e
F vsixtest/vsixtest_TemporaryKey.pfx e5b1b036facdb453873e7084e1cae9102ccc67a0
P 66629b2a0997ceedcfb38553f2200466b6c4e352ea00f8a0a7cb67a660c19523
R 9a9c201e8296e0260f25603d504d4def
U dan
Z 0d6df17481534a9055059794f33541b5
P fb83c3d8df250cb701fbe775b48ab93f5674496f68c57e04f50668c43c2de328
R f3d3274b176630163255462be6322523
U drh
Z 54cf8654d3e3811fdefd23ba6c7d6b42

2
manifest.uuid
View File

@@ -1 +1 @@
fb83c3d8df250cb701fbe775b48ab93f5674496f68c57e04f50668c43c2de328
4464f40ccd7c5553f4d44120ca6dac4e9445f08f083f7dcb3bd66b4413d818e0

23
src/select.c
View File

@@ -3382,11 +3382,12 @@ static void substSelect(
** (19) If the subquery uses LIMIT then the outer query may not
** have a WHERE clause.
**
** (20) If the sub-query is a compound select, then it must not use
** an ORDER BY clause. Ticket #3773. We could relax this constraint
** somewhat by saying that the terms of the ORDER BY clause must
** appear as unmodified result columns in the outer query. But we
** have other optimizations in mind to deal with that case.
** (**) Subsumed into (17d3). Was: If the sub-query is a compound select,
** then it must not use an ORDER BY clause - Ticket #3773. Because
** of (17d3), then only way to have a compound subquery is if it is
** the only term in the FROM clause of the outer query. But if the
** only term in the FROM clause has an ORDER BY, then it will be
** implemented as a co-routine and the flattener will never be called.
**
** (21) If the subquery uses LIMIT then the outer query may not be
** DISTINCT. (See ticket [752e1646fc]).
@@ -3520,9 +3521,6 @@ static int flattenSubquery(
** queries.
*/
if( pSub->pPrior ){
if( pSub->pOrderBy ){
return 0; /* Restriction (20) */
}
if( isAgg || (p->selFlags & SF_Distinct)!=0 || pSrc->nSrc!=1 ){
return 0; /* (17d1), (17d2), or (17d3) */
}
@@ -3557,6 +3555,15 @@ static int flattenSubquery(
*/
assert( (p->selFlags & SF_Recursive)==0 || pSub->pPrior==0 );
/* Ex-restriction (20):
** A compound subquery must be the only term in the FROM clause of the
** outer query by restriction (17d3). But if that term also has an
** ORDER BY clause, then the subquery will be implemented by co-routine
** and so the flattener will never be invoked. Hence, it is not possible
** for the subquery to be a compound and have an ORDER BY clause.
*/
assert( pSub->pPrior==0 || pSub->pOrderBy==0 );
/***** If we reach this point, flattening is permitted. *****/
SELECTTRACE(1,pParse,p,("flatten %s.%p from term %d\n",
pSub->zSelName, pSub, iFrom));