-----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-----
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
