On Thu, Oct 17, 2013 at 1:10 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
