Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> Why is the multi-valued IN expression special here? I would not expect the
> more-than-one element IN clause to obey different rules than a one element
> IN clause
> -- passing scenario - IN query with multiple anonymous composite types
> SELECT * FROM table1 WHERE column1 IN ('(0)', '(0)');

Yeah, that's pretty weird and non-orthogonal. With multiple non-Var
values on the RHS, transformAExprIn tries to make a ScalarArrayOpExpr,
for which it has to infer an array type for the array RHS, which it
does like this:

/*
* Try to select a common type for the array elements. Note that
* since the LHS' type is first in the list, it will be preferred when
* there is doubt (eg, when all the RHS items are unknown literals).
*/
allexprs = list_concat(list_make1(lexpr), rnonvars);
scalar_type = select_common_type(pstate, allexprs, NULL, NULL);

This is fishy for various reasons, but the performance advantages of
ScalarArrayOpExpr are enough that we avert our eyes from the corner cases.
(In practice, people don't tend to write IN lists with intentionally
varying RHS types anyway.)

Meanwhile, the single-element IN is handled exactly like "x = y".

regards, tom lane