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 operator preference?
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 can see far more logic to implicitly
casting text to double than I can text to interval, but if a cast to double
won't actually get you where you want and a cast to interval will... Maybe it's
possible to account for all those cases with just a boolean... maybe not.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
