> 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