-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gavin Sherry wrote:
| On Fri, 8 Oct 2004, Gaetano Mendola wrote:
|
|
|>Gavin Sherry wrote:
|> > On Wed, 6 Oct 2004, Josh Berkus wrote:
|> >
|> > [snip]
|> >
|> >
|> >>Of course, this is as true of functions as it will be of procedures. So half
|> >>the functionality that I'm angling for to support with calling named params
|> >>could be accomplished within the context of overloading just by extending the
|> >>named param patch in 8.0 to cover calling functions/SPs in the format above.
|> >
|> >
|> > 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) ...
|>
|>As I see the world ( it could be wrong ) these two functions above have
|>the same signature, so the second declaration shall be not allowed, do you
|>want put also the formal parameters names in the function signature ?
|>Orrible.
|
|
| Oops. Thought-o. I meant:
|
| create function foo(i int, j text) ...
| create function foo(j text, i int) ...
|
|
| Their signature is now:
|
| foo(int, text)
| foo(text, int)
|
| Which is legal.
Yes and doing this I think shall be impossible call these two functions with
named parameter, after all as Josh Berkush pointed out foo(anyelement) and
foo(anyarray) have the same problems and when you call foo(ARRAY[2,3]) postgres
complain.
Regards
Gaetano Mendola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBZdq57UpzwH2SGd4RApriAKDenxbP71nfu9saT5TcGSMTcbgE9wCglWKq
gdYfsWNGzwfAAdjwqA9uvMI=
=0f/k
-----END PGP SIGNATURE-----
