On Mon, Jul 26, 2010 at 3:07 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
