Horton

Re: 8.4 release planning

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Joshua Brindle <method@manicmethod.com>, Josh Berkus <josh@agliodbs.com>, Stephen Frost <sfrost@snowman.net>, Gregory Stark <stark@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, "Joshua D. Drake" <jd@commandprompt.com>, Merlin Moncure <mmoncure@gmail.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, Bruce Momjian <bruce@momjian.us>, Bernd Helmle <mailings@oopsware.de>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2009-01-27T20:07:46Z
Lists: pgsql-hackers 
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,

			regards, tom lane