On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure <mmonc...@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-gene...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers