Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Darren Duncan <darren(at)darrenduncan(dot)net>
Cc: Eric Ridge <eebbrr(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Date: 2011-10-31 00:56:53
Message-ID: CA+TgmoYrtRhRRh7wD-ziihQ-a0B1wOeijw6+D=85obwyp0nxdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 30, 2011 at 6:11 PM, Darren Duncan <darren(at)darrenduncan(dot)net> wrote:
> Eric Ridge wrote:
>>
>> I don't actually like the term "EXCLUDING", but it conveys what's
>> happening and is already defined as a keyword.  I thought about
>> "EXCEPT", but that doesn't work for obvious reasons, and "NOT" might
>> just be confusing.
>
> How about "BUT"?
>
> Is that already in use by something?  Its nice and short and conveys the
> "except" meaning.
>
> And there is already precedent for using that word for this purpose.
>
> CJ Date already uses "ALL BUT" in his literature as a modifier to his
> illustrative relation projection syntax to give the complementary
> projection, like with "r{x,y}" vs "r{all but x,y}".
>
> Also, a more tenuous connection, Larry Wall likes "but" as logical modifier.

Look, there's no good speculating about what might work without
sitting down and editing gram.y. The exact choice of keyword matters
a lot less than whether this can be done with out shift/reduce or
reduce/reduce conflicts.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Eric B. Ridge 2011-10-31 01:09:07 Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Previous Message Darren Duncan 2011-10-31 00:25:42 Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?