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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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:11:16
Message-ID: CA+Tgmoa8P+zBfJbv8axLRKwfs5wErXbCbvipWF2ZJf3MgeN8ng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-general by date

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

Browse pgsql-hackers by date

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