On Mon, Jul 26, 2010 at 3:07 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> I understand, but with only text accepting, then CONCAT will has much
>> less benefit - you can't do a numeric list, for example
>>
>> see concat(c1::text, ',', c2::text, ',' ...)
>>
>> with this is much simpler use a pipes '' || c1 || ',' || c2 ... and
>> this operator does necessary cast self.
>>
>> This function is probably one use case of exception from our rules.
>
> At least two, right?
correct: there would be at least two.
> Because for that use case you'd probably want
> concat_ws(). In fact, it's hard for me to think of a variadic text
> function where you wouldn't want the "no casts" behavior you're
> getting via ANY.
concat() is not a variadic text function. it is variadic "any" that
happens to do text coercion (not casting) inside the function. The
the assumption that concat is casting internally is probably wrong.
Suppose I had hacked the int->text cast to call a custom function -- I
would very much expect concat() not to produce output from that
function, just the vanilla output text (I could always force the cast
if I wanted to).
concat is just a function that does something highly similar to
casting. suppose I had a function count_memory(variadic "any") that
summed memory usage of input args -- forcing casts would make no sense
in that context (I'm not suggesting that you think so -- just bringing
up a case that illustrates how forcing cast into the function can
change behavior in subtle ways).
merlin