Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Date
Msg-id CA+TgmoYrtRhRRh7wD-ziihQ-a0B1wOeijw6+D=85obwyp0nxdQ@mail.gmail.com
Whole thread Raw
In response to Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Darren Duncan <darren@darrenduncan.net>)
Responses Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  ("Eric B. Ridge" <eebbrr@gmail.com>)
List pgsql-hackers
On Sun, Oct 30, 2011 at 6:11 PM, Darren Duncan <darren@darrenduncan.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


pgsql-hackers by date:

Previous
From: Darren Duncan
Date:
Subject: Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Next
From: "Eric B. Ridge"
Date:
Subject: Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?