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