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

From Pavel Stehule
Subject Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Date
Msg-id CAFj8pRB_+cjG66zBfhZDA7GpOBTpHHe0tXka-eMFpqga_7ej_w@mail.gmail.com
Whole thread Raw
In response to Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Eric Ridge <eebbrr@gmail.com>)
List pgsql-hackers
2011/11/1 Eric Ridge <eebbrr@gmail.com>:
> On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> some other idea - but only for psql
>>
>> we can define a special values, that ensure a some necessary
>> preexecution alchemy with entered query
>>
>> \pset star_exclude_names col1, col2, col3
>> \pset star_exclude_types xml, bytea, text(unlimited)
>>
>
> Sure, something like that could be useful too.  It might be confusing
> to users if they forget that they set an exclusion list, but there's
> probably ways to work around that.
>
> However, the nice thing about the feature being in SQL is that you can
> use it from all clients, and even in other useful ways.  COPY would be
> an example (something I also do frequently):
>
> COPY (SELECT * EXCLUDING (a, b, c) FROM <big query>) TO 'somefile.csv' WITH CSV;
>
> Right now, if you want to exclude a column, you have to list all the
> others out manually, or just dump everything and deal with it in an
> external tool.
>
> I generally agree with everyone that says using this in application
> code is a bad idea, but I don't think that's reason alone to reject
> the idea on its face.
>
> eric
>


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: unite recovery.conf and postgresql.conf
Next
From: Dimitri Fontaine
Date:
Subject: Re: psql expanded auto