Bruce Momjian wrote:
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.
Is it really possible?
It seems to me the simple_heap_insert() allows to put a value on
the preallocated fixed length field (like "oid"), but does not assume
a situation that whole of the HeapTuple is replaced. Thus, when PGACE
hook is invoked from inside the simple_heap_insert() and it replaces
the given tuple, the caller does not know it and believes the older
tuple was inserted. Does it makes a problematic behavior, isn't it?
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
