Looks like nested "case_searched" statements appear to break the ptWorkStack after switching the gwi.clauseType to SELECT in a WHERE condition.

The problem turns out to be a bit more complex than switching off where clause processing for the inner case.
If we leave the clauseType as WHERE, there's a chance logic somewhere might pop or not pop the stacks correctly. So we need to leave the change in. However, then things aren't popped off the stacks as they should be. But that's not the big problem.

The problem occurs because sometimes processing puts things on the ptWorkStack, and sometimes on the rcWorkStack. When we get to CASE processing, we don't know which, so we re-run the processing for each part. Then pop the appropriate stack. But we don't know which stack as I stated above, so there's no "appropriate" stack. Sometimes we guess wrong and things go haywire.

The fix includes a consolidation of the logic for WHERE and SELECT in buildCaseFunction(), wherein it pops stacks regardless of clauseType. Since we don't know what stack to pop (if any), we do a deep compare of the top of each stack against the newly created object. This is inefficient as the original processing sometimes puts the correct items on one of the stacks. We just don't know if or which. We redo that processing for each item and then deep compare to see which stack the item is on, if on any stack at all, and pop that stack.

There are comments in the code implying that there were plans to move to single stack processing. However those plans were never realized. Such an effort would be large but it might relieve some of the fragility in this section.

I commented a kludge I put in years ago for reasons that may be related. Said kludge seems to break case now. I don't remember if there were other reasons for the kludge (see RecursionCounter), so I left it in the code for now. I tried various nested functions and the regression tests also have such things which passed. The comment says MariaDB bug 750, but the old bug database appears to not be available any more.

Excellent work!

For QA: please use my test case in the developers comment.

Build verified: 1.1.4-1 source

/root/columnstore/mariadb-columnstore-server
commit 5199dd1a096fd3457e8fc0508bf5fb24cedec435
Merge: fce3c5e e554e04
Author: David.Hall <david.hall@mariadb.com>
Date: Wed Apr 11 11:04:46 2018 -0500

Merge pull request #108 from mariadb-corporation/MCOL-1331

MCOL-1331 Fix CASE1.DM.sql

/root/columnstore/mariadb-columnstore-server/mariadb-columnstore-engine
[root@localhost mariadb-columnstore-engine]# git show
commit ae04b8a6877c87f3ed3566f2bf721bf285ca625f
Merge: 2ab632c dbcbd6c
Author: david hill <david.hill@mariadb.com>
Date: Tue Apr 10 10:55:56 2018 -0400

Merge pull request #438 from mariadb-corporation/MCOL-1323

MCOL-1323 cpimport Splitter has incorrect SIGPIPE mapping

diff --cc writeengine/splitter/we_splitterapp.cpp
index f52f362,0077ebd..402d2b0
mode 100755,100644..100755
— a/writeengine/splitter/we_splitterapp.cpp
+++ b/writeengine/splitter/we_splitterapp.cpp

Executed the mentioned test case in 1.1.3-1 and had 20 rows returned.

Verified using the fixed version, as well as innodb, empty set was returned.