Re: 8.4 release planning

Поиск
Список
Период
Сортировка
От Joshua Brindle
Тема Re: 8.4 release planning
Дата
Msg-id 497F6B9C.3030307@manicmethod.com
обсуждение исходный текст
Ответ на Re: 8.4 release planning  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote:
>>> Josh Berkus wrote:
>>>> Hmmm.  Why try to hide individual rows in tables then?  That would seem 
>>>> not in keeping with the filesystem policies.
>>> Because rows have data in them. It is analogous to not allowing the contents of 
>>> the file to be visible. However, the primary key is still known to exist through 
>>> various means, which is more analogous to the filename.
> 
>> Since most keys are likely to be non-meaningful IDs, its not going to
>> help you much.
> 
> Even more to the point: if the expectation is that you can hide a row's
> data payload but not its primary key, you can accomplish that with
> column-level permissions, without having to get into any non-standard
> or even faintly surprising SQL behavior,
> 

We aren't saying we want to hide the payload of the data in an entire column, 
just the data in some of the rows. For example, if you have top secret and 
secret data in the same table a secret user would be able to see the entire row 
for secret rows but maybe only some of the data on the top secret rows (or maybe 
not see the rows at all).

Further, the top secret rows may have some fields that are inaccessible but are 
accessible through a trusted stored procedure that does fuzzing on the data 
(back to the coordinates example I used earlier)


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: pg_upgrade project status
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: pg_upgrade project status