On Sun, Aug 9, 2009 at 12:27 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Now that I've started to read this patch ... exactly what is the > argument for allowing a "mixed" notation (some of the parameters named > and some not)? ISTM that just serves to complicate both the patch > and the user's-eye view, for no real benefit.
Wow, I can't imagine not supporting that. Doesn't every language that supports anything like named parameters also support a mix? LISP is the obvious example, but I think most major scripting languages (Perl, Ruby, etc.) support something akin to this through a trailing hash argument. C# apparently supports both for something called attribute classes (don't ask me what they are). Ada also supports both styles, and you can mix them. http://msdn.microsoft.com/en-us/library/aa664614(VS.71).aspx http://goanna.cs.rmit.edu.au/~dale/ada/aln/8_subprograms.html#RTFToC11 The case where this is really useful is when you have lots of parameters most of which don't need to be set to a non-default value most of the time, but a few of which always need to be specified. In C you might do something like this: int frobozz(int common1, int common2, struct frobozz_options *fopt); /* fopt == NULL for defaults */ void init_frobozz_options(struct frobozz_options *); ...but the named/mixed syntax is more compact, and certainly nice to have, even if I'm emphatically not in love with the syntax we're stuck with. ISTM that the Ada rule that all positional must proceed all named is a good one, and to resolve the problem you're talking about here it seems we should probably also make a rule that specifying a value for the same parameter more than once (either both position and named, or named twice) is an error. It would also be quite reasonable to impose a requirement that parameters can only be specified using named notation if it has been explicitly enabled for that particular parameter. In LISP, there are four kinds of parameters (required, optional, rest, keyword) and any particular parameter gets to be exactly one of those four things. The rule for resolving ambiguities may not be what you want, but it's well-defined and pretty reasonable. http://gigamonkeys.com/book/functions.html#mixing-different-parameter-types ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers