Rafał Rzepecki <divided.mind@gmail.com> writes:
> I'm pretty sure the original intent was to afford some extra checks so
> that conditions such as "ROW(1, 2) IN ((ROW(3, 4), ROW(5, 6, 7))"
> would get rejected at parsing time (CCing the original author; please
> confirm).
No; the reason it was like that was that when that code was written,
make_row_comparison_op was the only way to compare two row values at
all. We didn't have record_eq and friends; nor did we have arrays
of composites.
> Since the restriction seems a rather arbitrary (at least I fail to see
> any reason for it), it can be removed altogether (patch 0002, not
> tested as well):
This is reasonable as far as it goes, but I think it doesn't go far
enough --- there's really no reason anymore to reject RowExprs as
components of ScalarArrayOpExpr either. I've extended this patch
some and committed it. Thanks for the report!
regards, tom lane