> The flaw in that argument is that as you are doing it, the > de-optimization only happens on queries that actually need the behavior. > As the SEPostgres patch is constructed, the planner could *never* trust > an FK for optimization since it would have no way to know whether row > level permissions might be present (perhaps only for some rows) at > execution time. You could only get back the optimization in builds with > SEPostgres compiled out. That's pretty nasty, especially for packagers > who have to decide which build setting will displease fewer users.
OK, I think I am starting to understand your concern now. My understanding of how the world works is SE-PostgreSQL would always be compiled in but could be turned off at run-time with a GUC. I know that the original design called for a compile-time switch, but everyone hated it and I am pretty sure KaiGai changed it. If he hasn't, he will. :-) There was also talk of having a table-level option to include/exclude the security ID (I'm not sure if it's currently implemented that way). Obviously that wouldn't be relevant for row-level MAC (because presumably you would need/want that turned on for all tables) but it would be very relevant for row-level DAC (because it's easy, at least for me, to imagine that you would only turn this on for a subset, possibly quite a small subset, of your tables where you knew that it was really needed). If, by default, we make sepostgresql disabled, MAC security IDs on newly created tables off, and DAC security IDs on newly created tables off, then the pain will be confined to people who explicitly request sepostgresql or row-level DAC. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
