In bug #9817 there's a complaint that the planner fails to consider these expressions equivalent: foo('a'::text, 'b'::text) foo(variadic array['a'::text, 'b'::text]) when foo() is declared as taking variadic text[].
Such cases worked okay before 9.3, the reason being that the use of VARIADIC disappeared after parsing, so that the two calls were in fact identical. However, once we added FuncExpr.funcvariadic, they're not identical anymore. I thought for a bit that we could fix this easily by having equal() disregard funcvariadic; there is precedent for that, since it ignores other fields that are just for display purposes and have no semantic impact, such as CoercionForm and location. Unfortunately, funcvariadic *does* have semantic impact on a few functions that use get_fn_expr_variadic, such as format(). Since the planner has no good way to know which ones those are, it cannot safely ignore funcvariadic while matching expressions. In short, commit 75b39e790 broke this rather badly, and I don't see any easy way out. We could possibly salvage something by redefining funcvariadic as only being true if VARIADIC was used *and* the function is VARIADIC ANY, so that it returns to not being different for semantically-equivalent cases. This would be a bit messy, since it would not un-break the behavior for any already stored rules or indexes in 9.3 databases. But I'm not sure there is any good way to make the problem magically go away in 9.3 databases. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers