Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
От | Darren Duncan |
---|---|
Тема | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? |
Дата | |
Msg-id | 4EADB6FB.40705@darrenduncan.net обсуждение исходный текст |
Ответ на | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? (Eric Ridge <eebbrr@gmail.com>) |
Ответы |
Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
|
Список | 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 по дате отправления: