Skip site navigation (1) Skip section navigation (2)

Re: mixed, named notation support

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Steve Prentice <prentice(at)cisco(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mixed, named notation support
Date: 2009-08-09 18:27:44
Message-ID: 603c8f070908091127t510fbfd7iaeff558033dcd1ee@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Aug 9, 2009 at 2:17 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Aug 9, 2009 at 12:27 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-08-09 18:29:44
Subject: Re: Review: Patch for contains/overlap of polygons
Previous:From: Bruce MomjianDate: 2009-08-09 18:20:03
Subject: Re: Review: Patch for contains/overlap of polygons

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group