Re: BUG #8198: ROW() literals not supported in an IN clause

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