On Fri, Jan 30, 2009 at 5:37 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
