Re: [PATCH] pg_sleep(interval) - Mailing list pgsql-hackers

On Wed, Oct 16, 2013 at 5:16 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 10/16/13 2:40 PM, Robert Haas wrote:
>> On Wed, Oct 16, 2013 at 1:26 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>> Also, as Tom pointed out, at some point we have to either say we really
>>> support overloading or we don't.
>>
>> We clearly do support overloading.  I don't think that's at issue.
>> But as we all know, using it can cause formerly unambiguous queries to
>> become ambiguous and stop working.
>
> But that's not really what this is.  It's one thing to be wary about
> adding foo(bigint, int, smallint) when there are already three other
> permutations in the system.  (At least in other languages, compilers
> will give you warnings or errors when this creates an ambiguity, so
> there's no guessing.)  But the problem here is that if there already is a
>
>     foo(type1)
>
> then the proposal to add
>
>     foo(type2)
>
> can always be shot down by
>
> "But this will break foo('type1val')."
>
> That can't be in the spirit of overloading.
>
> The only way to fix this is that at the time when you add foo(type1) you
> need to prevent people from being able to call foo('type1val') and
> instead require the full syntax foo(type1 'type1val').  The only way to
> do that, I think, is to add some other foo(type3) at the same time.
> There is just something wrong with that.

Actually, this could be fixed by having a way to declare one of the
overloaded functions as the preferred option and resolving ambiguous
calls in favor of the highest-priority function.  In fact,
EnterpriseDB has added just such an option to Advanced Server 9.3, and
it fixes several longstanding difficult choices between being
Oracle-compatible and being PostgreSQL-compatible; we're now more
compatible with both.  If we had that option in PostgreSQL, we could
declare the existing function as the preferred option, add the new
one, and be pretty much assured of not breaking anything.

However, I've learned from experience that submitting patches to
improve PostgreSQL's only-marginally-usable ambiguous function
resolution code is an exercise in futility.  My last attempt ended
with a clear majority of people telling me that they liked failing to
call *the only function called foo* when confronted with a call that
was clearly intended to reference that function.  As nearly as I can
tell, people like the idea of such unnecessary failures only in
theory.  As soon as it comes to any practical case (like this one),
people start looking for workarounds.  Right now there aren't any good
ones, and the reason for that is simple: we refuse to entertain adding
them.

Just sayin'.

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