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

=?UTF-8?Q?Rafa=C5=82_Rzepecki?= <divided(dot)mind(at)gmail(dot)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