Ron Mayer <rm...@cheapcomplexdevices.com> writes: > It seems to me that there are two different standards to which this feature > might be held.
> Is the goal > a) SEPostgres can provide useful rules to add security to some > specific applications so long as you're careful to avoid crafting > policies that produce bizarre behaviors (like avoiding restricing > access to foreign key data you might need). On the other hand it > gives you enough rope to hang yourself and produce weird results > that don't make sense from a SQL standard point of view if you > aren't careful matching the SEPostgres rules with your apps. > or > b) SEPostgreSQL should only give enough rope that you can not > craft rules that produce unexpected behavior from a SQL point > of view; and that it would be bad if one can produce SEPostgres > policies that produce unexpected SQL behavior. With my other hat on (the red one) what I'm concerned about is whether this patch will ever produce a feature that I could turn on in the standard Red Hat/Fedora build of Postgres. Right at the moment it seems that the potential performance hit, for users who are *not using* SEPostgres but merely have to use a build in which it is present, might be bad enough to guarantee that that will never happen. 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