Re: [PATCH] ACE Framework - Database, Schema - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] ACE Framework - Database, Schema
Date
Msg-id 603c8f070912140348q5ae80cb2s7b80596459745fd6@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] ACE Framework - Database, Schema  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: [PATCH] ACE Framework - Database, Schema  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
List pgsql-hackers
2009/12/14 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> Robert Haas wrote:
>> 2009/12/13 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>>>> Just to name a few really obvious problems (I only looked at the
>>>> 01-database patch):
>>>>
>>>> 1. We have been talking for several days about the need to make the
>>>> initial patch in this area strictly a code cleanup patch.  Is this
>>>> cleaner than the code that it is replacing?  Is it even making an
>>>> attempt to conform to that mandate?
>>> Even if it is unclear whether the current form is more clear than the
>>> current inlined pg_xxx_aclcheck() form, or not, it will obviously
>>> provide a set of common entry points for upcoming enhanced security
>>> providers.
>>> Eventually, it is more clear than enumeration of #ifdef ... #endif
>>> blocks for SELinux, Smack, Solaris-TX and others.
>>
>> Right, but it will also not get committed.  :-(
>
> The framework will be necessary to get them committed.
> Which is an egg, and which is a chicken? :-(

We've been around that path a few times, but that's not my point here.Doing the framework first makes a lot of sense;
theproblem is that 
we just had a design discussion regarding that framework and you've
chosen to do something other than what was discussed.  Did you not
read that discussion?  Did you not understand it?

Unfortunately, what this project has turned into is a very long series
of patch submissions that all basically have the same problems.  The
code is messy.  It doesn't conform to project style.  It embeds
undiscussed design assumptions that the community does not endorse.
It has poorly factored interfaces that may serve SE-PostgreSQL
adequately for the moment but are likely to require constant
rejiggering as new problems arise.  It is filled with shims that don't
accomplish anything useful and other places where useful shims are
left out.

Now, it may be that even if you respond to all of the comments and fix
all of the issues that people are concerned about, the patch still
won't get committed.  As you know, Tom is very skeptical that the
user-base for this feature is large enough to warrant the work that it
will take.   But my point is that you seem to be very deliberately not
fixing those problems, and I don't see how we're going to make any
progress that way.  Many of the problems that I found in my review of
this patch were covered in design discussions that happened this week,
and yet the patch shows almost no evidence of those design
discussions.

Frankly, I find that kind of depressing.

...Robert


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby, release candidate?
Next
From: tomas@tuxteam.de
Date:
Subject: Re: Range types