Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Hmm. If that's the expected application environment then the patch as
proposed has fatal performance problems anyway, for lack of a way to
get rid of no-longer-referenced pg_security rows. We had been led to
understand that there wouldn't be all that many distinct labels in use,
but this seems to imply that there are going to be $bignum of them.
That changes pg_security leakage from a can-live-with-for-first-cut
issue to a must-fix-to-be-credible issue.
It's worth noting that this is yet another thing that is mostly a
problem in the context of row-level security. It seems to me that if
security labels are only applied to tables and columns, then it will
be possible to scan the whole database relatively quickly and find all
the labels that are still in use, probably without breaking a sweat.
On the other hand, when you have row-level security, it gets a lot
harder.
If we are not labeling every row, why not just use a TEXT column without
using an OID to reference pg_security; there aren't that places,
pg_class, pg_attribute, etc, i.e. they are not on every data row.
We should not assume every row are not labeled forever, at least.
It will lose expandability soon.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
