Re: Function call

On Tue, 27 Jan 2004, Tom Lane wrote:

> each candidate.  func_select_candidate depends on having some notion of
> the "same argument position", but what does that mean in such a case?

While it is true that I don't know everything about the current code I 
still claim that it can not be such a big problem as you try to paint 
a picture of here. And even more importantly, even if it is it should not 
affect the current behaviour, more about that later.

If you have function:
  f(x int, y text)  f(y float, x text);

and you make a call
   f(2,'foo');

then for each candidate above there is some matching going on based on the 
order of the arguments. I just assume that this works as it should today, 
even if I don't know the details. Not everyone have worked with PG before 
and knows everything directly.

Now, lets assume there is a call
    f (y => 2, x => 'foo')

then for each candidate the order is fixed again. I hoped to treat it 
differently for each candidate, so the possible calls are
   f('foo',2)   f(2, 'foo')

and these orders are the same every time we look at a candidate.

Now, the above is just my plan before coding and before understanding 
everything. It might work and it might not. So far I've got no reason to 
thing that it wont work,

Let's assume that I can't make something like the above to work as fast
as today. For functions calls without named arguments then the current
fast function can still be used. Only for the new kind of calls do you
need to do something more fancy. That would make named calls be "a lot"
slower (relatively speaking) then calls without named and a fixed order of
the arguments. The problem here is not speed but code duplication.

> 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?

That is an open question, one can go either way. I think both will work 
and both will be understandable/predictable from the programmers point of 
view.

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

At first I plan to not have the argument names as part of the signature.
Mainly because if one start without one can add it later if needed.  To
have it part of the signature only lets you define more functions then
today. The other database that implements this does have the argument
names as part of the signature.

I think that the value of having it is no that big. Just don't name your
functions and arguments like that. Rejecting cases like that above will 
not make life harder for the programmer. It would rather help him/her 
designing better functions. If it hurts, don't do it.

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

That would suck big time.

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

There will be no hit at all since the functions calls for these don't use 
named arguments, the exact same method of function resolution as today 
should work fine. You just need to detect at the start if this function 
call is with or without named arguments. I have never had any plans of 
slowing down the current method, including the fast case where all 
arguments have the correct types. I'm sure I will run into problems, like 
the above and/or others. I'll have to deal with it when I run into it.

There is of course another way all this can turn out also, that I don't 
manage to make it work in a good way. In that case there will be no named 
parameter function calls (unless somebody else makes them).

In any case, let me try to make it work before we throw it away. I work on
pg on some free hours here and there. It might take some time until I have
something working, but when I do I would love for you to review the patch
pointing out all errors!

The worst that can happen is that it doesn't work. So what, I can live 
with that :-)

-- 
/Dennis Björklund