2013/1/20 Robert Haas <robertmh...@gmail.com>: > On Sun, Jan 20, 2013 at 3:21 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
