Re: SQL-Invoked Procedures for 8.1

Gavin Sherry <swm(at)linuxworld(dot)com(dot)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)

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

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.

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.

regards, tom lane