=?UTF-8?Q?Rafa=C5=82_Rzepecki?= <divided.m...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
