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

From Darren Duncan
Subject Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Date
Msg-id 4EADB6FB.40705@darrenduncan.net
Whole thread Raw
In response to Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Eric Ridge <eebbrr@gmail.com>)
Responses Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
List pgsql-hackers
Eric Ridge wrote:
> On Sun, Oct 30, 2011 at 4:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That's just a gut feeling, I've not tried it ... but the proposed
>> syntax sure looks a lot like a call to a function named EXCLUDING.
> 
> I think what makes it okay is that its new use is only defined to
> immediately follow an asterisk in the "target_el" production.  If you
> look at gram.y:11578 (from git HEAD), I was thinking this:
<snip>

That's an interesting thought.

I had previously envisioned EXCLUDING to appear exactly once in the SELECT list, 
where it functions as a column analogy to EXCEPT for rows.  So you'd say:
  SELECT <list of stuff to keep> EXCLUDING <list of stuff to skip> FROM ...

But then your comment makes me think that your EXCLUDING actually could have a 
much tighter scope, and as a result might appear multiple times, like AS can:
  SELECT foo.* EXCLUDING foo.x, bar.* EXCLUDING bar.y, baz.z, (a+b) AS c FROM ...

So if you do this, EXCLUDING has syntactic precedence similar to AS, and while 
AS is only valid not following a *, EXCLUDING is only valid following a *, and 
so EXCLUDING directly modifies a single * and not the SELECT list in general.

Is that where you're going with this?

If so, I think that would make the feature even more valuable and more 
syntactically clean than I had previously thought.

-- Darren Duncan


pgsql-hackers by date:

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