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 <kaigai@ak.jp.nec.com>