On Sun, Aug 9, 2009 at 2:17 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 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? > > I don't know if that's true, [...]
I'm fairly sure it is. > and I definitely don't know if they all > handle corner cases identically. I'm 100% positive that they don't. > I think this patch is an exercise in > guessing at what the SQL committee will eventually do, and as such, we > should avoid like the plague making any guesses that carry significant > risk of being semantically incompatible with what they eventually do. > The risk/reward ratio isn't good enough. I completely agree; I would have chosen to boot the entire patch for exactly that reason. However, given that you don't seem to want to do that, I was just offering my thoughts on the various possible methods of eliminating that risk, since the one you're suggesting doesn't seem ideal to me. I thought that perhaps providing some examples of how other programming languages handle this problem might be helpful - in particular, I think the Lisp model, where each parameter must be EITHER named or positional, has a lot to recommend it. There is little doubt here that what gets committed here will be what you choose to commit. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers