KaiGai Kohei wrote:
> > If we use some type of integer, I suggest using this structure for
> > pg_security:
> >
> > CREATE TABLE pg_security(
> > relid oid,
> > secid int2,
> > secacl aclitem[],
> > secext TEXT
> > );
> >
> > This allows the per-row value to be a simple int2. It also improves
> > maintenance because rows are associated only with a specific table;
> > unused values can then be removed more easily. And it allows both
> > secacl and secext security to be specified.
>
> How does the approach resolve the pain of user interface?
> I don't think packing two or more values into one field is not a right way.
I see later emails that say we have to have both security methods
available at the same time, and the table above does that. There would
be one security oid on every row and it would refer to this table.
pg_security would contain every _unique_ combination of secacl and
secext. On INSERT the code looks to see if the secacl/secext exists in
pg_security, and if it does it reuses the same oid, if not it adds a new
row. (There is no method for cleaning out unreferenced pg_security rows
(relid was supposed to help with that but it also bloats pg_security)).
Some people didn't like it was per-table so I removed the relid column:
CREATE TABLE pg_security( secid oid, secacl aclitem[], secext TEXT);
pg_dump and COPY would dump the per-row oid and pg_security so there
should be only one flag to dump security info, even though it supports
two security methods.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +