Tom Lane wrote:
This case *must* work:
create function foo (f1 int)
create function foo (f1 int, f2 int = 42)
select foo(10)
and it seems like just an arbitrary exception if you don't have a rule
about preferring fewer defaults over more.
I tried out C++, and it rejects this case:
#include <iostream>
using namespace std;
int foo(int f1) { return 1; }
int foo(int f1, int f2 = 42) { return 2; }
int foo(int f1, int f2 = 42, int f3 = 43) { return 3; }
int main() {
cout << foo(10) << endl;
}
test.cpp: In function 'int main()':
test.cpp:9: error: call of overloaded 'foo(int)' is ambiguous
test.cpp:4: note: candidates are: int foo(int)
test.cpp:5: note: int foo(int, int)
test.cpp:6: note: int foo(int, int, int)
Interestingly, it complains about the calls, not the declarations, which
is what I might have argued against.
So, I'd rather reject the foo(10) call. The least-defaults rule doesn't
strike me as very appealing. If you are porting Oracle functions with
40 arguments, it's very confusing and error-prone to say that the
35-defaults variant will be called over the 37-default variant, more so
if you extend this to name-based parameter lists where parameters and
defaults can be in any order. The whole thing is probably a mistake and
should be rejected.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
