From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Date: | 2008-12-12 03:59:15 |
Message-ID: | 200812120359.mBC3xFr26989@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
We have had discussion on whether we want one or two security columns;
there have been comments on both sides.
Have we decided if we are going to use some type of integer on every row
that points to a pg_security row or put the value right in the row?
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.
I am unsure how an insert into a 'security_context' column would
automatically insert into pg_security however. I am also unclear how
COPY would work.
Also, having the per-row value always be present in the row and
controlled by the bitmask seems ideal; it avoids having to add a CREATE
TABLE option.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | ITAGAKI Takahiro | 2008-12-12 04:08:12 | Re: Looking for someone with MinGW |
Previous Message | Fujii Masao | 2008-12-12 03:53:44 | Re: Sync Rep: First Thoughts on Code |