Re: SQL-Invoked Procedures for 8.1

On Thu, 7 Oct 2004, Tom Lane wrote:

> Gavin Sherry <swm@linuxworld.com.au> writes:
> > We cannot use named parameter notation with functions due to overloading.
> > Disregarding the idea of default values, consider:
>
> > create function foo(i int, j int) ...
> > create function foo(j int, i int) ...
>
> > If we did:
>
> > SELECT foo(j => 1, i => 2)
>
> > we would have two candidate functions. So, AFAICT, we cannot used named
> > parameters with functions. :-(
>
> It's not really as bad as that.  Defaults are killers, but I think that
> named params per se are tolerable.  Consider that the above pair of
> functions would be disallowed anyway because they are both foo(int,int)
> --- the param names are not part of the primary key of pg_proc, and I
> don't want to see them become so.  So a realistic case would be more
> like
>
> create function foo(i int, j int) ...
> create function foo(j int, i float) ...
>
> SELECT foo(j => 1, i => 2)

Yes, I made a thought-o. See my post to Gaetano's email.

>
> and in this case the first foo would be chosen as being an exact match
> to the integral input types.  (Whether that's reasonable is somewhat
> beside the point here; it's how things work in positional parameter
> matching, and I'd expect the same in name-based parameter matching.)
> Having param names would actually reduce the amount of ambiguity since
> you could immediately discard any candidates with a non-matching set
> of parameter names.
>
> [ thinks some more... ]  Actually I guess the problem comes with
>
> create function foo(i float, j int) ...
> create function foo(j int, i float) ...

This is what I meant to point out -- oops.

>
> which is a legal pair of functions from a positional viewpoint, but
> would look identical when matching by names.  We'd have to think of some
> way to forbid that.

Well, we'd error out in the function candidate selection code as it stands
now, I'd say, but we may need to do some work to make the actual error
more user friendly.

>
> The main thing that I'm not happy about is the syntax.  I'm going to
> resist commandeering => for this purpose, and I don't see any way to use
> that symbol for this without forbidding it as a user-defined operator.
> I previously suggested using AS, which is already a fully reserved word,
> but that suggestion seems not to have garnered any support.

I agree that => restricts people in a way we are not at the moment. AS
is a better idea but I also like IS, which makes more sense to me. IS is
currently on the func_name_keyword list -- I *think* we could use it.
What do you think?

>
>             regards, tom lane
>

Gavin