Pavel Trukhanov <pavel.trukhanov@gmail.com> writes:
> Though I might've used wrong words to describe my holdback here, what
> I meant is that I'll need to create new node type (in primnodes.h?)
> for IN-list, that will allow to differentiate it from direct "ARRAY"
> usage.
> This will require changes to parse_expr.c, execExpr.c, etc, which
> seems to be overkill for such issue IMO, hence the question.
I do not think you need new expression infrastructure. IMO what's going
on here is that we're indulging in premature optimization in the parser.
It would be better from a structural standpoint if the output of parse
analysis were closer to what the user wrote, and then the business of
separating Vars from Consts and reducing the Consts to an array were
handled in the planner's expression preprocessing phase.
So maybe what you should be thinking about is a preliminary patch that's
mostly in the nature of refactoring, to move that processing to where
it should be.
Of course, life is never quite that simple; there are at least two
issues you'd have to think about.
* The parsing phase is responsible for determining the semantics of
the query, in particular resolving the data types of the IN-list items
and choosing the comparison operators that will be used. The planner
is not allowed to rethink that. What I'm not clear about offhand is
whether the existing coding in parse analysis might lead to different
choices of data types/operators than a more straightforward approach
does. If so, we'd have to decide whether that's okay.
* Postponing this work might make things slower overall, which wouldn't
matter too much for short IN-lists, but you can bet that people who
throw ten-thousand-entry IN-lists at us will notice. So you'd need to
keep an eye on efficiency and make sure you don't end up repeating
similar processing over and over.
regards, tom lane