>>> The length of HeapTupleData is determined during heap_form_tuple(), >>> and it is unchanged later. Thus, we have to interpose here, as object >>> identifier doing. >> Currently yes. Is there a reason not to? Do we rely on the tuple length >> staying same after those operations? >> >> Just considering multiple ways of making the context optional. > > Indeed, we can consider several options. > > However, I don't want to change existing semantics in the core implementation > as far as possible. If we have to choose one of them, I prefer to add > TupleDesc > a bool variable to show necessity of security field, because it requires many > points to be updated, but most of them are obvious.
Ah, however, it made an explosion of the number of points to be patched soon. I'll try your approash in first, as follows: 1. When the SECURITY_SYSATTR_NAME is defined, heap_form_tuple() always allocate a field to store security attribute. 2. The security mechanism can store its security attribute on the hooks for insert or update tuples. It also can remain the field as InvalidOid. 3. The modified heap_insert() and heap_update() cut off the security field and moves backward region by sizeof(Oid) bytes, when it is remained as InvalidOid. > Anyway, I've started to work with the prior approach. > Now we have less than two weeks remained in the CommitFest:Nov, so we have > no time to be spent uselessly. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
