Re: Updates of SE-PostgreSQL 8.4devel patches

Robert Haas wrote:
>> Can you *do* the row-level permission?
>
> I don't think there's any consensus on a design.

Yes, unfortunatelly.
No one replied to my proposed design:
http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2

> Getting consensus on a design seems to actually be one of the harder
> aspects of PostgreSQL development. The pattern seems to be:
>
> 1. Someone submits a patch. By definition, the patch embodies some
> particular design.
> 2. One or more members of core express concerns about the design
> embodied in the patch.
> 3. If the concerns are fairly specific and not mutually contradictory,
> the submitter revises the patch accordingly and it gets committed
> (hopefully without having to discard too much of their previous work).
> 4. If the concerns are fairly vague and open-ended, or if they
> contract each other, the patch hovers in limbo for eternity.
>
> I'm not sure what the solution to this problem is. The fact that a
> member of core does not like a particular design for feature X does
> not oblige that person to produce a better one, but it's pretty tough
> to proceed without it.

Yes, I have had similar experiences in Linux kernel development for
several years.
The amount of time to get consensus is one of the reason why I want
to move the SQL based row-level security to v8.5 development cycle.

> In the case of SE-PostgreSQL, two members of core expressed concerns:
>
> - Peter Eisentraut expressed concern about implementing row-level
> security via SE-PostgreSQL without first implementing some sort of
> SQL-based row-level security. KaiGai expressed willingness to
> implement that, but we still don't have a design, so I assume KaiGai
> is going to implement... something... and hope that it turns out to be
> acceptable.

Its conclusion is actually not clear for me.
The proposed SQL based row-level security assumes what he pointed out
is right, but I don't know the reason why it should be placed prior.

I guess he intend to share the code for row-level security, thus it
should be implemented prior to the OS specific feature. But most of
SE-PostgreSQL code is separated from core implementation and invoked
via security hooks, so it is unsuitable to share code with other
facilities.

In my preference, I want to pay my efforts for OS-independent row-level
security in the v8.5 cycle with enough days, and want to concentrate for
SE-PostgreSQL in the v8.4 cycle, as I mentioned before.
But I will do, if it is unacceptable.

> - Tom Lane expressed concerns about covert channels to which KaiGai
> responded, AIUI, that the patch was pretty useful even without
> addressing that issue, but if Tom isn't willing to see the patch
> committed otherwise, then KaiGai has to decide between giving up and
> attempting to implement some form of polyinstantiation - which will
> not be easy, and which is far from guaranteed to be accepted if he
> does develop it.

Its conclusion it not clear.

I think the polyinstantiation is too much requirements, as prior major
commercial RDBMS with row-level security (like Oracle Label Security)
does not care about such kind of covert channels.
It is quite natural to describe such kind of limitation/specification
on the documentation explicitly to help end-user's decision.

> In both cases, the lack of a clear roadmap means that a dedicated
> developer is potentially putting in a lot of time and effort
> developing what may end up being a complete dead-end.

I believe such a situation will help nobody get happy.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>