Re: proposal: fix corner use case of variadic fuctions usage

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