Re: Function call

Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> writes:
> On Tue, 27 Jan 2004, Tom Lane wrote:
>> 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).

You're not thinking this through. The reordering might be different for
each candidate. func_select_candidate depends on having some notion of
the "same argument position", but what does that mean in such a case?

There are also some difficult questions raised by schemas and search
paths. s1.f1(text, text) masks s2.f1(text, text) if s1 appears before
s2 in your search path. But does s1.f1(foo text, bar text) mask
s2.f1(baz text, xyzzy text)? Does your answer change depending on
whether the actual call has parameter names or not? For that matter,
should f1(foo text, bar text) and f1(baz text, xyzzy text) be considered
to be different function signatures that ought to be permitted to
coexist in a single schema? If actual parameter names are going to
affect resolution of search-path ambiguity, it's hard to argue that the
parameter names aren't part of the signature.

What might be the best compromise is to treat parameter names as
documentation *only*, that is, we insist that the parameters have to
appear in the declared order in any case. All we do with the names in a
call (if supplied) is check that they match the function declaration
after we have resolved which function is meant using the existing
methods.

>> (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.

Yes it does.

> About the speed, how many functions do you have with the same name.

Try "select proname, count(*) from pg_proc group by 1 order by 2 desc;"
Note that the ones at the top are pretty popular in usage, not only in
having lots of variants. I don't think it's acceptable to take major
speed hits in parsing them, especially not if the hit occurs whether
one uses the named-parameters feature or not ...

regards, tom lane