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

From Christopher Browne
Subject Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Date
Msg-id CAFNqd5X9C8TtemdQjKPRLeLD=FxGdgoT2i-NEL1UB=QZ-Yz_Rg@mail.gmail.com
Whole thread Raw
In response to Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?  (Mark Mielke <mark@mark.mielke.cc>)
List pgsql-hackers
On Sun, Oct 30, 2011 at 7:46 PM, Mark Mielke <mark@mark.mielke.cc> wrote:
> In the above case - maybe you don't want password - what about social
> insurance number, credit card number, or any other private bit? The only way
> to truly know you aren't accidentally pulling in fields you don't need or
> want to unnecessarily expose on the wire - is to specifically list the
> fields you DO want, which is precisely to not use "*" at all.

A fairly useful characteristic case would be related to this, namely...
   select * excluding password from some_table;

The sensitive bits of data are often fairly well enumerated, so it's a
useful-ish idea to pull everything except that.

The joys and challenges may be pretty well characterized by:
 create view sanitized_table as   select * excluding password from some_table;

Now, if someone running queries somewhere downstream is sufficiently
lacking in clue that they don't know which columns they *do* want,
then it seems dubious to me that letting them exclude the columns that
they imagine that they know they *don't* want is actually valid.

That is, if they don't know what they want (e.g. - the column set in a
traditional sans-EXCLUDES query), then I'm rather suspicious that they
aren't competent to build a proper EXCLUDES clause.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Next
From: Darren Duncan
Date:
Subject: Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?