Re: [PATCH] pg_sleep(interval)

On Thu, Oct 17, 2013 at 9:51 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas escribió:
>> 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.
>
> How does this work?

In Advanced Server, we've added implicit casts between some data types
between which PostgreSQL does not have implicit casts.  We do this
because Oracle implicitly casts between those data types, and having
similar casts allows function calls that would succeed on Oracle to
also succeed on Advanced Server.  Unfortunately, it also renders some
operators, particularly textanycat and anytextcat, ambiguous.  In
existing releases of Advanced Server, we handled that by removing
those operators.  This creates some breakage in edge cases:
concatenation with text still works fine for the data types for which
we added implicit casts to text, but for other data types it fails
where it would have succeeded in PostgreSQL.

In Advanced Server 9.3, we added a new pg_proc column called
proisweak.  When a function or operator call would otherwise be
rejected as ambiguous, we check whether all but one of the remaining
candidates are marked proisweak; if so, we select the non-weak
candidate.  Advanced Server 9.3 now marks the textanycat and
anytextcat operators as weak rather than removing them; this allows
type-with-an-implicit-cast-to-text || text to work, because we now
have a way to prefer implicit cast + textcat to anytextcat.

Obviously, the implicit casts are not for PostgreSQL and would be
rightly rejected here, but I am not sure that the ability to prefer
one function or operator over others in an overloading situation is
such a bad idea.  So far, our internal testing seems to show that it
works well and doesn't break things.

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