On Sun, Aug 9, 2009 at 7:30 PM, Tom Lane<t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers