On Thu, Oct 17, 2013 at 1:10 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 10/17/2013 10:01 AM, Robert Haas wrote:
>> 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.
>
> The other argument for doing it at the function level is that we could
> then expose it to users, who could use it to manage their own overloaded
> functions. We would NOT want to encourage users to mess with cast
> precedence, because it would be impossible for them to achieve their
> desired result that way.
>
> On the other hand, prioritization at the function level likely wouldn't
> help us with operators at all, because there the cast has to be chosen
> before we choose a function. So if we pursued the function route, then
> we'd eventually want to add a "preferred" flag for operators too. Which
> would be a lot more trouble, because it would affect the planner, but at
> least that would be a seperate step.
Actually the operator resolution code is very much parallel to the
function resolution code. I am quite sure in Advanced Server we only
needed to add proisweak to handle both cases; unless I'm quite
mistaken, we did not add oprisweak.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
