On Sun, Jan 20, 2013 at 3:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I suppose this complaint is based on the idea that we could have
> declared format() as format(fmt text, VARIADIC values text[]) if
> only the argument matching rules were sufficiently permissive.
> I disagree with that though. For that to be anywhere near equivalent,
> we would have to allow argument matching to cast any data type to
> text, even if the corresponding cast were explicit-only. Surely
> that is too dangerous to consider. Even then it wouldn't be quite
> equivalent, because format() will work on any type whether or not
> there is a cast to text at all (since it relies on calling the type
> I/O functions instead).
Well, as previously discussed a number of times, all types are
considered to have assignment casts to text via IO whether or not
there is an entry in pg_cast. So the only case in which my proposal
would have failed to make this work is if someone added an entry in
pg_cast and tagged it as an explicit cast. I can't quite imagine what
sort of situation might justify such a perplexing step, but if someone
does it and it breaks this then I think they're getting what they paid
for. So I think it's pretty close to equivalent.
> While VARIADIC ANY functions are surely a bit of a hack, I think they
> are a better solution than destroying the type system's ability to check
> function calls at all. At least the risks are confined to those
> specific functions, and not any function anywhere.
I think this is hyperbole which ignores the facts on the ground. Over
and over again, we've seen examples of users who are perplexed because
there's only one function called wumpus() and we won't call it due to
some perceived failure of the types to match sufficiently closely.
Destroying the type system's ability to needlessly reject
*unambiguous* calls is, IMHO, a feature, not a bug.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company