Re: 8.4 release planning - Mailing list pgsql-hackers

From Joshua Brindle
Subject Re: 8.4 release planning
Date
Msg-id 497F6B9C.3030307@manicmethod.com
Whole thread Raw
In response to Re: 8.4 release planning  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pg_upgrade project status
Next
From: "Joshua D. Drake"
Date:
Subject: Re: pg_upgrade project status