Re: proposal: fix corner use case of variadic fuctions usage

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> We introduced VARIADIC "any" function. Motivation for this kind of
>> function was bypassing postgresql's coerce rules - and own rules
>> implementation for requested functionality. Some builtins function
>> does it internally - but it is not possible for custom functions or it
>> is not possible without some change in parser. Same motivation is
>> reason why "format" function is VARIADIC "any" function.

> I'd just like to draw the attention of all assembled to the fact that
> this is another example of the cottage industry we've created in
> avoiding our own burdensome typecasting rules.

I suppose this complaint is based on the idea that we could have
declared format() as format(fmt text, VARIADIC values text[]) if
only the argument matching rules were sufficiently permissive.
I disagree with that though. For that to be anywhere near equivalent,
we would have to allow argument matching to cast any data type to
text, even if the corresponding cast were explicit-only. Surely
that is too dangerous to consider. Even then it wouldn't be quite
equivalent, because format() will work on any type whether or not
there is a cast to text at all (since it relies on calling the type
I/O functions instead).

While VARIADIC ANY functions are surely a bit of a hack, I think they
are a better solution than destroying the type system's ability to check
function calls at all. At least the risks are confined to those
specific functions, and not any function anywhere.

regards, tom lane