Re: Issues for named/mixed function notation patch

On Sun, Aug 9, 2009 at 7:30 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 1. As I already mentioned, I think the mixed-notation business is a bad
> idea.  It's unintuitive, it's not especially useful, and it substantially
> increases our risk of being semantically incompatible with whatever the
> SQL committee might someday do in this area.  I think we should disallow
> it until we see what they do.  I gather that this might be an unpopular
> position though.

It seems like we could safely allow the cases which are unambiguous.
Namely where the call has a sequence of unnamed parameters followed by
some named parameters all of which refer to parameters which come
later.

So foo(1,2,3 as x,4 as y) would be legal as long as x and y were not
one of the first three arguments.

That's a pretty common idiom when you have a function which does
something normal to the first few arguments and then has a bunch of
non-standard modes which can be optionally invoked. Take for example
the perl DBI's connect method which takes a data source, username,
authentication token, then a list of parameters which can be any of
dozens of parameters (actually it takes a fifth argument which is a
hashref -- but the point here is just that it's a common style, not
that we should be copying perl's solution).

The reason I'm saying this is safe is because there's just no other
possible interpretation. As long as it only covers the unambiguous
cases then there's no other meaning other implementations can define
which this would conflict with.

--
greg
http://mit.edu/~gsstark/resume.pdf