> > I don't think partitioning is really the same thing as row-level security.
>
> Of course not, but it seems to me that it can be used to accomplish most
> of the same practical use-cases. The main gripe about doing it via
> partitioning is that the user's nose gets rubbed in the fact that there
> can't be an enormous number of different security classifications in the
> same table (since he has to explicitly make a partition for each one).
Imho a useful partitioning feature that is worth extra syntax additions
will have to include the ability to automatically create partitions on demand
(and maybe remove empty ones during vacuum).
(I have refrained from discussing partitioning until now, because I thought
this is not the time. But the certainty with which manual creation
is implied here makes me nervous.)
I short it (imho) requires a partitioning clause (much like a group by clause in sql)
and optionally an expression to produce a partition name (+ maybe for the nostalgic
a tablespace name mapping expression).
If partitioning for row level sec includes a sec column as proposed,
I think the two could be combined as a means for performance optimization.
But I am not sure partitioning alone can efficiently replace the sec column approach.
(especially in the admittedly unlikely >100 sec label scenario).
(When a constraint says the partition only contains visible security labels,
the sec check can be done at the partition level (including CE for denied labels))
Andreas