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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Vik Reykja <vikreykja(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: fix corner use case of variadic fuctions usage
Date: 2013-01-20 22:42:55
Message-ID: CAFj8pRCfRDY+cNvg76orKYCBCwU6bfdvBcb7FuFV1ccspsE6NA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

2013/1/20 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sun, Jan 20, 2013 at 3:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Robert James 2013-01-21 00:28:24 Re: Understanding TIMESTAMP WITH TIME ZONE
Previous Message Pavel Stehule 2013-01-20 22:38:09 Re: proposal: fix corner use case of variadic fuctions usage

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-01-20 23:53:05 Re: Removing PD_ALL_VISIBLE
Previous Message Pavel Stehule 2013-01-20 22:38:09 Re: proposal: fix corner use case of variadic fuctions usage