Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
От | Christopher Browne |
---|---|
Тема | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? |
Дата | |
Msg-id | CAFNqd5X9C8TtemdQjKPRLeLD=FxGdgoT2i-NEL1UB=QZ-Yz_Rg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? (Mark Mielke <mark@mark.mielke.cc>) |
Список | 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 по дате отправления: