Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

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 17:59:51
Message-ID: 200812121759.mBCHxpj08326@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2008-12-12 18:01:40 Re: benchmarking the query planner
Previous Message Bruce Momjian 2008-12-12 17:57:59 Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)