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