Re: get_fn_expr_variadic considered harmful - Mailing list pgsql-hackers

From Tom Lane
Subject Re: get_fn_expr_variadic considered harmful
Date
Msg-id 23975.1396377217@sss.pgh.pa.us
Whole thread Raw
In response to Re: get_fn_expr_variadic considered harmful  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-01 12:52:54 -0400, Tom Lane wrote:
>> 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.

> It's pretty damn ugly, but if we're going for magic in around those
> edges, we could just force the new behaviour in readfuncs.c. IIUC all
> the neccessary data for it is there.

I don't want either readfuncs or equalfuncs going in for catalog lookups,
which is what they'd have to do to fix it at that level (the key point
being they'd have to find out whether the called function is declared as
VARIADIC ANY).  Too much risk of unpleasant side effects if we do that.
The parser, on the other hand, has ready access to the function's
parameter list when building a FuncExpr.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: get_fn_expr_variadic considered harmful
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: decreasing memory needlessly consumed by array_agg