Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?

Поиск
Список
Период
Сортировка
От Eric Ridge
Тема Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Дата
Msg-id CANcm6wb_5+PU7ggJpc56CLiewys47Kwxvu0kxNyNg2pBu8O6XA@mail.gmail.com
обсуждение исходный текст
Ответ на Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Eric Ridge <eebbrr@gmail.com>)
Ответы Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Nov 1, 2011 at 12:03 PM, Stephen Frost <sfrost@snowman.net> wrote:
>  Note- I haven't looked at the * production or tried to do anything w/ gram.y to
> support this yet, but it's a heck of a lot shorter..

My original thought, that I probably didn't explain too clearly, was
to make the "EXCLUDING (...)" bit a modifier to the A_Star node.  The
idea being that you could write "* EXCLUDING (...)" anywhere you can
currently write "*".

It's dead simple for the case of:    SELECT * FROM ...
but because of the "indirection" productions in gram.y, it's literally
impossible for:    SELECT tablename.* FROM ...
without possibly breaking existing queries.

Nonetheless, even if it were only available for the first form, it
would be very useful.  For the ad-hoc type stuff I do, it'd still be
great to write:   SELECT * EXCLUDING (x.a, x.b, x.c) FROM (SELECT .... x);

I've already got gram.y working the way it needs to, and I've started
to get the exclusion list passed into the places it needs to go.

If y'all would be willing to accept it in this "limited" form, I'll
continue to work on it.

eric


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: unite recovery.conf and postgresql.conf
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: Compiler branch prediction hints (was: So, is COUNT(*) fast now?)