Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
От | Eric Ridge |
---|---|
Тема | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? |
Дата | |
Msg-id | CANcm6wbZaicLqKqo1S9CQtF0fMEvN7nYY+04u-oCtA_x3SUwHw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
|
Список | pgsql-hackers |
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: | a_expr { $$ = makeNode(ResTarget); $$->name = NULL; $$->indirection = NIL; $$->val = (Node *)$1; $$->location = @1; } + | '*' EXCLUDING '(' columnref_list ')' + { + /** make magic happen */ + } | '*' { ColumnRef *n = makeNode(ColumnRef); n->fields = list_make1(makeNode(A_Star)); n->location = @1; $$ = makeNode(ResTarget); $$->name = NULL; $$->indirection = NIL; $$->val = (Node *)n; $$->location = @1; } And it looks like something similar would be necessary in the "indirection_el" production, around line 11478. But that might be overly simplistic (and wrong). eric
В списке pgsql-hackers по дате отправления: