On Thu, Oct 17, 2013 at 12:45 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> 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.
>
> Hmmm. Is this better to do on the cast level or the function level?
> For the case discussed, it would be sufficient to have a way to mark a
> particular function signature as "preferred" in cases of ambiguity, and
> that would be a lot less likely to have side effects. Mind you, fixing
> the cast in general would fix far more annoying cases, but I also see it
> as something which would be very hard to get correct ...
This is of course to some degree a matter of opinion. The ankle bone
is connected to the leg bone, and the leg bone is connected to the
knee bone, and all that. It's very legitimate to think that we can
change the system in a variety of places to fix any given problem.
But if you're asking my opinion, I think doing it on the function
level is a whole lot better and easier to get right. A flag like the
one I mentioned here can be set for one particular function with the
absolute certainty that behavior will not change for any function with
some other name. That type of surety is pretty much impossible to get
with casts.
It's also not clear to me that the rules are logically related to the
input data type. We might prefer to choose pg_sleep(double) over
pg_sleep(interval) on backwards-compatibility grounds, but some other
function might be in the opposite situation. You can't really get a
lot of fine-grained control with casting here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
