On Tue, 27 Jan 2004, Tom Lane wrote:
> In particular, how will you avoid individually trawling through every
> function with a matching name to try to match up the arguments?
I don't think you can avoid that. But it's just done once to find the oid
of the real function, so if it's used multiple times in the same query
it's not that bad.
In most cases you don't have that many functions with the same name
anyway.
I've looked at the current code that finds the correct function and it
looked doable. But, I wont know until I make the implementation. And don't
hold your breath, I can't work all the time on this, so a couple of days
work might take a couple of weeks. I have some code already, but it's
not nearly done.
> func_select_candidate() that involve comparing matches at "the same
> argument position" will break down completely.
I was planning to reorder the arguments before the matching according to
the function prototype so I can reuse the old select_candidate (more or
less, the reordering needs to be done for each matching). But if it's not
that simple I will just have to solve it in some more difficult way. In
any case, the currect semantics will stay the same.
> (Adding default values would make overloaded functions an order of
> magnitude slower yet, not to mention outright ambiguous.)
The ambigious part i've complained about to the people that have asked me
for the feature. Now I've come to the conclusion that it doesn't really
matter if it's ambigious. If I can't find one function that match then
I'll just throw an error. There are still a lot of cases where it is
useful and where there are no amiguities.
About the speed, how many functions do you have with the same name. I
don't think I've ever seen more then 10 or something. It should not be
that slow to iterate over that a couple of times (I hope). It will never
be as fast as a direct call, with the correct types of course. Of course I
still like it to be fast, but it can never be as fast.
--
/Dennis Björklund