Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date
Msg-id 200812121759.mBCHxpj08326@momjian.us
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
List pgsql-hackers
KaiGai Kohei wrote:
> >>> 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.
> >> Sorry, I don't understand why it related to a CREATE TABLE option.
> >> System columns are always allocated for any tables?
> > 
> > Does a table use storage for the security column if no SQL-level
> > security value is supplied for a given row?
> 
> When Row-level ACL is enabled on the table and user suppies a tuple
> without any specific ACLs, it requires security field, because the
> length of HeapTuple is decided at heap_form_tuple() which is invoked
> prior to fetching the user supplied ACLs.
> 
> When Row-level ACL is disabled (by pg_class.reloptions) on the table,
> the storage for security field is not necessary.

It is possible to re-call heap_form_tuple() once we know we need a
security field;  I talked Tom about that.  We can worry about it later.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Next
From: Tom Lane
Date:
Subject: Re: benchmarking the query planner