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

From Eric Ridge
Subject Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Date
Msg-id CANcm6wb_5+PU7ggJpc56CLiewys47Kwxvu0kxNyNg2pBu8O6XA@mail.gmail.com
Whole thread Raw
In response to Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Eric Ridge <eebbrr@gmail.com>)
Responses Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
List 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 by date:

Previous
From: Robert Treat
Date:
Subject: Re: unite recovery.conf and postgresql.conf
Next
From: Merlin Moncure
Date:
Subject: Re: Compiler branch prediction hints (was: So, is COUNT(*) fast now?)