On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote: > It's unclear for me what is the point you said. > I guess you concern the fixed length field is always allocated in > the case when any security feature is not enabled also, or performance > degradation on the large scale databases. > If incorrect, please tell me in another expression. > > At first, the fixed length 4 byte field is allocated only when > the SE-PostgreSQL (or other security feature) is enabled. It can be > controlled via PGACE hook. The pgaceSecurityAttributeNecessary() can > return bool value, and it indicates the necessity of the security > field. If SE-PostgreSQL is disabled on compile-time or run-time, > the fixed length 4 byte value is not allocated.
I'm sorry for not making my thoughts clearer. Let me try again: As I understand it, when enabled, the overhead for each row is more than 4 bytes because you include a text field also, which you say has a restricted number of values. IMHO the overhead is unacceptable, given that our row overhead is already high. I would prefer to make the maximum overhead per row 4 bytes only, which matches the maximum number of required labels. This will allow very large databases to use this feature. I would also like to see the feature part of normal Postgres, rather than as a compile time option. The per-row overhead would then be optional, just as WITH OIDS is optional. This would allow many applications to take advantage of row level security, without the need for switching to a different executable and without the need to enable it for every table. For high security applications, default_row_security = on would obviously be a requirement. With a single executable on all distros we will have more robust software and it will be easier to configure and use. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
