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

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: (view raw, whole thread or download thread mbox)
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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

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

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