Re: Variadic parameters vs parameter defaults
От | Tom Lane |
---|---|
Тема | Re: Variadic parameters vs parameter defaults |
Дата | |
Msg-id | 13132.1229556686@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Variadic parameters vs parameter defaults ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: Variadic parameters vs parameter defaults
|
Список | pgsql-hackers |
"Pavel Stehule" <pavel.stehule@gmail.com> writes: > 2008/12/17 Gregory Stark <stark@enterprisedb.com>: >> My inclination would be to say zero arguments is zero arguments and you get a >> zero-length array. We could eliminate the problem with anyelement by saying >> the variadic argument can't be the only polymorphic argument. > I disagree. Polymorphism is strong feature and without it, you have to > repeat code. Or maybe divide this problem to two cases: zero typed > variadic arguments, and nnempty polymorphic variadic argument. Yeah, I don't like putting extra restrictions on the polymorphic case either. Also, see my nearby note about how letting fewer defaults win over more defaults might be unsafe. Consider foo (f1 int)foo (f1 int, f2 variadic int[]) If the system allows f2 to be defaulted to zero elements, then these two functions would have to be considered ambiguous under the stricter rule. This would make it *impossible* for the user to override the default zero-argument behavior, even with the trick of using an additional function. Under the rules that I'm pushing, the above two declarations are not ambiguous because you need at least two actual arguments to match the second one. They would be ambiguous if you explicitly specified a default for f2, but there's no reason to do so if you want this type of combination. regards, tom lane
В списке pgsql-hackers по дате отправления: