Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 0.9.0-incubating
-
Fix Version/s: 0.9.2-incubating
-
Component/s: None
-
Labels:None
Description
The uniquify(String, Set<String>, Suggester) method in SqlValidatorUtil tries to create a unique name for the supplied name. It does it inside the following loop which does not have an upper bound check. If the suggester returns a name that already exists in the nameList, then the loop will never terminate. I encountered this issue while doing some testing with a 3 way join query in Drill against text data.
for (int j = 0;; j++) {
name = suggester.apply(originalName, j, nameList.size());
if (nameList.add(name)) {
return name;
}
}
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
I was going to say that it was not my problem, it was the fault of the person that wrote the suggester – then I see that I wrote the suggester. 
I'll fix it.
Do you have a SQL query as test case, or other suggestion how to reproduce the problem?
Hah! This query reproduces it, by cunningly using exactly the same alias as the uniquifier would be inclined to generate:
select "$f2", max(x), max(x + 1) from (values (1, 2)) as t("$f2", x) group by "$f2"
Fixed in my branch https://github.com/julianhyde/optiq/tree/optiq-439. Waiting for commits to open before I push to master.
Bulk update closing "fixed" issues that are more than a year old.
For F_SUGGESTER, using the 'attempt' counter instead of size of the list when creating the unique name fixes the problem. However, a few plan tests fail due to different field names. I haven't confirmed if those are expected diffs. (Note that the EXPR_SUGGESTER already uses 'attempt' counter.).