Andres Freund writes:
> On Tuesday, April 12, 2011 09:00:40 PM Tom Lane wrote:
>> Hm, well, you got a better idea? I definitely want it *short*, because
>> these are going to be in a lot of places.
> Not really. Maybe DirectFunctionCall1Coll or even DirectFCall1Coll...
xxxFunctionCallNColl wou
On Tuesday, April 12, 2011 09:00:40 PM Tom Lane wrote:
> Andres Freund writes:
> > On Tuesday, April 12, 2011 08:09:53 PM Tom Lane wrote:
> >> 1. The existing names with a "C" appended (eg, OidFunctionCall2C) will
> >> take a collation argument (in particular, this replaces the existing
> >> Direc
Andres Freund writes:
> On Tuesday, April 12, 2011 08:09:53 PM Tom Lane wrote:
>> 1. The existing names with a "C" appended (eg, OidFunctionCall2C) will
>> take a collation argument (in particular, this replaces the existing
>> DirectFunctionCall1WithCollation and DirectFunctionCall2WithCollation,
On Tuesday, April 12, 2011 08:09:53 PM Tom Lane wrote:
> 1. The existing names with a "C" appended (eg, OidFunctionCall2C) will
> take a collation argument (in particular, this replaces the existing
> DirectFunctionCall1WithCollation and DirectFunctionCall2WithCollation,
> which seem a bit verbosel
I wrote:
> So, unless there's a really good reason why fn_collation should be in
> FmgrInfo and not FunctionCallInfo, I'm going to see about moving it.
It looks like the single largest PITA involved in this change is that
the FunctionCallN/OidFunctionCallN/DirectFunctionCallN families of
functions
The fact that the collations patch put fn_collation into FmgrInfo,
rather than FunctionCallInfo, has been bothering me for awhile. The
collation is really a kind of argument, not a property of the function,
so FmgrInfo is logically the wrong place for it. But I'd not found a
concrete reason not t
