Simon Riggs wrote: > On Tue, 2008-11-18 at 16:51 +0900, KaiGai Kohei wrote: > >> Anyway, I've started to work with the prior approach. > > Sounds good.
The matters currently I faces: * In the approach.1 (add "tdhassecurity" to TupleDesc) An explosion of the number of points to be patched. :( * In the approach.2 (strip security field in heap_insert/update, if unused) Some implementations assumes an older and newer tuple have same length of its header, However, a security field can be striped in the heap_insert/update(), if unused. Thus, this approach has to allow them to have different length between older tuple and a result of heap_form_tuple(). In this approach, we have to list up all the implementations which assume fixed length tuple-header, and fix them. ---- My preference is second one. It will also enable to clean up many of "hasoid" bool abound the implementation. However, I want to challenge the enhancement at the v8.5 development cycle, as a part of writable "oid" system column feature. (I have a plan to propose the feature next to the SE-PostgreSQL.) A concern is why you suggested this feature at the last half of the November. :( *Now*, I don't want to merge the feature to disable row-level security into the current patch set, because it damages qualities of the codes. Is there any other opinions? 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
