Thanks for the feedback. I thought once again about separating IN from ARRAY, with refactoring etc as Tom suggested, and now I don't think it's worth it to do so. I've tried to implement that, and besides that it will require to change things in every part of query processing pipeline, it seems that most of the times I will have to repeat (copy/paste) for IN case all the code that now works in for ARRAY. At first I though there will be simplifications, that will justify such refactoring - i.e. I thought I could at least drop "multidims" bool that tells ARRAY[] from ARRAY[ARRAY[]]. But it turns out it's not the case – one can write something like "x IN (ARRAY[1], ARRAY[1,2])" that will result in multidim IN-list array.
So I don't think there's actually enough benefit to split those two apart. Now I want to do this: just add a meta info (basically a bool field) to the ArrayExpr struct, so on later stages we could tell if that's an ArrayExpr of an ARRAY or of an IN list. Plus to add ignoring updating Jumble for expression subtree within IN-list array. If that approach doesn't seem too bad to anyone, I would like to go forward and submit a patch – it seems pretty straightforward to implement that. Thoughts? Thank you. --- Pasha Trukhanov
