On Tue, Nov 27, 2012 at 12:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I admit that there are cases where this could happen, and that it will
>> happen a little more than it does now. But, as you say, this can
>> happen now, and yet we get very few if any complaints about it,
>> whereas we get regular complaints about the need to insert casts that
>> other database systems do not require. The fact is that most
>> functions are not overloaded, so the esoterica of overloading affect
>> only a tiny number of relatively sophisticated users. The need for
>> extra casts cuts a much broader swath through our user base.
>
> I find this argument a bit specious. It probably is true that most
> *user defined* functions aren't overloaded --- but that's not so true
> for system-defined functions, and even less true for operators. So
> the parser's behavior with overloaded calls affects all users, whether
> they know it or not. It also affects developers, in that adding a
> new overloaded version of a system function (that previously wasn't
> overloaded) could actually reduce the number of cases for which the
> function works without an explicit cast.
>
> We have got to be really careful with changing the parser's behavior
> here, or we're going to break cases that work today.
Well, the whole point of writing the patch the way I did was that it
*doesn't* break any cases that work today.
But as to your point about the system catalogs, it is true that adding
an additional function could reduce the number of cases where things
work today. But I think in many cases it would eliminate the need for
overloading that we already have, and simplify things for future
developers. Right now, quote_literal() allows implicit casts to text
by having a second version that takes any anyelement argument; on the
other hand, concat() allows implicit casts to text by accepting "any"
rather than text as an argument; and || allows implicit casts to text
by defining operators for anynonarray || text, text || anynonarray,
and text || text. So we've got three quite different methods to
create implicit-cast-to-text behavior in particular cases. That's got
developer complexity too, and while this proposal wouldn't do anything
about the third case since || actually sometimes has a different
meaning, namely array concatenation, the first two wouldn't need
overloading any more. They'd just work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
