On Fri, Jan 30, 2009 at 5:37 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Bruce,
>> Are you trying to make some kind of point?
>>
>
> Yeah, that we're certainly not doing any of this for 8.4.
>
> If we're going for radical new approaches for row-level, why not also look
> at the VIEWS approach? If we worked out the same problems we need to fix
> for Bernd's patch, using automated manatory views to enforce row-level
> access is also plausible.
I'm rather enchanted with the idea of using table partitioning to
implement row-level security, but the obstacles seem rather
formidable. Right now, a partitioned relation behaves nothing like a
regular relation, and to use it for this purpose you'd need to make it
transparent. IOW, you'd need to be able to define indices that
spanned multiple partitions (including enforcement of unique
constraints), you'd need to be able to make foreign keys that could
point to a row in arbitrary subset of the partitions, you'd need
automatic creation and deletion of partitions, you'd need better
planner support for partitions, and you'd need to somehow deal with
the issue of pg_class bloat. Plus, to make it truly transparent,
you'd need multiple layers of partitioning, in case someone wanted to
do row-level security and range partitioning simultaneously.
Now, the plus side is that if we could do all of that, we'd have the
infrastructure to support some truly awesome partitioning stuff, and
not just row-level security. But it seems awfully hard.
...Robert
