2013/1/20 Robert Haas <robertmhaas@gmail.com>:
> 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.
I am thinking so VARIADIC ANY functions is only one possible solution
for functions with more complex coercion rules like oracle DECODE
function. Just modification coercion rules is not enough - or we need
to thinking about extensible parser and analyser.
Regards
Pavel
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company