Robert Haas wrote:
> > 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.
Yes, if there is concern about row-level security turning off
optimizations, some flag would have to be checked so the optimization
would be possible for sites not using row-level security; ideally there
would be a table-level flag, and I think the current patch implements it
that way.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
