Re: Updates of SE-PostgreSQL 8.4devel patches

> Can you *do* the row-level permission?

I don't think there's any consensus on a design.

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.

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.

- 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.

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.

...Robert