On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>> CONCAT('foo', NULL) => 'foo' really the behavior that everyone else
>>> implements here? And why does CONCAT() take a variadic "ANY"
>>> argument? Shouldn't that be variadic TEXT?
>>
>> What does that accomplish, besides forcing you to sprinkle every
>> concat call with text casts (maybe that's not a bad thing?)?
>
> You could ask the same thing about the existing || operator. And in
> fact, we used to have that behavior. We changed it in 8.3. Perhaps
> that was a good decision and perhaps it wasn't, but I don't think
> using CONCAT() to make an end-run around that decision is the way to
> go.
It was absolutely a good decision because it prevented type inference
in ways that were ambiguous or surprising (for a canonical case see:
http://www.mail-archive.com/pgsql-general@postgresql.org/msg93224.html).
|| operator is still pretty tolerant in the 8.3+ world.
select interval_col || bool_col; -- error
select interval_col::text || bool_col; -- text concatenation
select text_col || interval_col || bool_col; -- text concatenation
variadic text would require text casts on EVERY non 'unknown' argument
which drops it below the threshold of usefulness IMO -- it would be
far stricter than vanilla || concatenation. Ok, pure bikeshed here
(shutting my trap now!), but concat() is one of those wonder functions
that you want to make as usable and terse as possible. I don't see
the value in making it overly strict.
merlin