On 10/17/13 8:06 AM, Robert Haas wrote:
> 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.
That might be worth discussing. I'd prefer somehow getting rid of the
unknown literals/type, but that's a different discussion.
> 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.
Well, that was a proposal to make things more loose, and it's reasonable
to have issues with that. On the other hand, making things more strict
is obviously prone to break existing code. So it's indeed difficult to
make any changes either way.
