KaiGai Kohei wrote:
> >>> Here is our OID column on some rows but not others:
> >>>
> >>> test=> CREATE TABLE test (x INT) WITH oids;
> >>> CREATE TABLE
> >>> test=> INSERT INTO test VALUES (1);
> >>> INSERT 16392 1
> >>> test=> ALTER TABLE test SET WITHOUT OIDS;
> >>> ALTER TABLE
> >>> test=> INSERT INTO test VALUES(2);
> >>> INSERT 0 1
> >>> test=> SELECT oid, * FROM test;
> >>> ERROR: COLUMN "oid" does not exist
> >>> LINE 1: SELECT oid, * FROM test;
> >>>
> >>> but it has per-table granularity; the oid value for '1' is still
> >>> stored, but is no longer visible; that would not work for the security
> >>> value.
> >> If we can control the Row-level ACLs via table options, what should be
> >> happen when we turn off the feature?
> >> IMO, it is natural to ignore Row-level ACLs independent from whether
> >> the stored tuple actually has ACLs, or not.
> >
> > Hmmm, sounds like perhaps a GUC is needed there.
>
> Is it possible to control per-table granuality?
> Or, per-table control is not necessary?
Well, we have a GUC which controls whether tables get an OID column.
If we do the 'secacl' on a per-table level we should probably have a GUC
which would default to ON for all created tables.
Perhaps someone can chime in here to tell us how hard it would be to
allow system columns to be null and not take any storage space, i.e. use
HeapTupleHeaderData.t_infomask on a per-row basis and not
HeapTupleHeaderData.t_bits.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +