Andrew Sullivan <a...@crankycanuck.ca> writes: > On Wed, Jan 28, 2009 at 01:49:21PM -0500, Joshua Brindle wrote: >> The costs are nil for people who don't want this feature.
> That's also false, because developers who don't care about the feature > have to continue to maintain it as part of the system. If maintenance > were free, I suspect nobody would be objecting to the feature. But > this feature will in fact constrain future development and will impose > maintenance requirements on the programmers of the system. Right. The major implementation problem I have with row-level security is that it will require sticking its hands into every part of the backend; at least if you want it to be actually *secure* with no holes, and if not I guess I'm failing to grasp the point. Every future patch will have to be vetted to ensure that it's not accidentally breaking that security. This stems directly from the fact that you're trying to impose behavior that's fundamentally at odds with SQL, and therefore there isn't any well-defined choke point at which you could apply the checks and be done with it. The system simply isn't modularized that way. (Of course we could throw it all away and start over...) BTW, in regard to the upthread question about how much of the patch could be discarded if we removed row-level security: having now taken another look through it, I'd put the fraction at well north of 90%. (That's exclusive of the security policy file, which I don't understand at all and so can't tell how much might be specific to row security.) What's worse, the current patch footprint is conservative because the placement of hooks is simply wrong. You can't usefully apply checks in simple_heap_insert, for example, since it has no idea who called it or why. It's got to be done at a higher level and therefore in a lot more places. And I don't see any attempt at all to restrict system-driven fetches, yet surely there has to be some control over that (otherwise why are we worrying about system-driven updates?) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers