On 10/17/13 12:10 PM, Josh Berkus 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.
Yeah, but hasn't every case of this that we've run into been directly related to casting problems, and not function or
operatorpreference?
ISTM that exposing the idea of function priority to users is opening a massive Pandora's box...
Something else I'm wondering is if priority should actually be something that's numbered instead of just a boolean. I
cansee far more logic to implicitly casting text to double than I can text to interval, but if a cast to double won't
actuallyget you where you want and a cast to interval will... Maybe it's possible to account for all those cases with
justa boolean... maybe not.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
