Robert Haas wrote:
> 2009/6/30 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> The SE-PostgreSQL patches are updated as follows:
>> 01) http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.4-r2096.patch
>> 02) http://sepgsql.googlecode.com/files/sepgsql-02-core-8.4-r2096.patch
>> 03) http://sepgsql.googlecode.com/files/sepgsql-03-gram-8.4-r2096.patch
>> 04) http://sepgsql.googlecode.com/files/sepgsql-04-writable-8.4-r2096.patch
>> 05) http://sepgsql.googlecode.com/files/sepgsql-05-rowlevel-8.4-r2096.patch
>> 06) http://sepgsql.googlecode.com/files/sepgsql-06-perms-8.4-r2096.patch
>> 07) http://sepgsql.googlecode.com/files/sepgsql-07-extra-8.4-r2096.patch
>> 08) http://sepgsql.googlecode.com/files/sepgsql-08-utils-8.4-r2096.patch
>> 09) http://sepgsql.googlecode.com/files/sepgsql-09-tests-8.4-r2096.patch
>> 10) http://sepgsql.googlecode.com/files/sepgsql-10-docs-8.4-r2096.patch
> It appears that some things that you were previously asked to remove
> for the first version, like row-level security, have crept back in
> here. I think that there is a clear consensus that what you have here
> is too ambitious for a single commit.
The row-level security is added at the fifth patch.
If you apply only the first three patches, it performs without row-level
I don't believe all the 10 patches get commited at the first commit fest.
If preferable, I can agree to forcus on the first three patches on the first
commit fest, according to the step-by-step approach, previously suggested.
01 ... It provides a facility to manage security labels of database obejcts.
02 ... It provides a core access control stuff including communication with kernel.
03 ... It provides SECURITY_LABEL option in some of CREATE/ALTER statement.
> To put some numbers around this:
> $ cat *.patch | diffstat | tail -1
> 219 files changed, 11819 insertions(+), 29 deletions(-), 857 modifications(!)
Some of files are parched by multiple patches.
It is more correct estimation.
$ diffstat sepgsql-00-full-8.4.0-r2096.patch.gz
165 files changed, 11788 insertions(+), 2 deletions(-), 657 modifications(!)
> For comparison:
> Infrastructure Changes for Recovery
> 8 files changed, 912 insertions(+), 183 deletions(-)
> Window Functions
> 92 files changed, 6631 insertions(+), 232 deletions(-)
> WITH/WITH RECURSIVE
> 77 files changed, 5826 insertions(+), 246 deletions(-)
> Based on that, it looks to me like you should really aim to have a
> patch set that changes AT MOST 5-6K lines, and less would be improve
> your odds of having something accepted. You can always submit
> follow-on patches once the basic implementation is in, but I think I'm
> reflecting the shared view of those who have looked at this in the
> past when I say that it's never going to get committed in this form.
Scale of the first three patches is as follows:
$ diffstat sepgsql-01-sysatt-8.4.0-r2095.patch \
110 files changed, 5162 insertions(+), 2 deletions(-), 308 modifications(!)
The SE-PostgreSQL without row-level security version changes about 5-6K lines.
I can agree it may be a maximum scale in a single commit fest.
> Just to be clear, the fact that you have split this up into multiple,
> separate patch FILES is of no value at all, because they are
> interdependent. For example, I just took a quick look at the "01"
> patch and it obviously includes code that is only necessary for
> row-level security. Nothing is going to get committed here unless it
> is a self-contained change that does not presume that there will be
> further commits in the future.
I considered the separated patches reflects the step-by-step approach
previously suggested. At least, the minimum SE-PostgreSQL can works
with the first two patches.
The purpose of 01 patch is to provides a facility to manage security
labels of any database objects, including tables, columns and so on.
However, indeed, I could find a part only necessary for row-level stuff,
such as definitions of "security_labels" and "security_acl".
I can agree to move them to the later patch.
> Unless this is resubmitted in a form that complies with the changes
> that were requested the last time it was reviewed, there is really no
> point in reviewing it again.
Right now, I think it is preferable to focus on the first three patches
at the first commit fest.
What's your opinion?
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2009-07-03 02:59:34|
|Subject: Re: Synch Rep: direct transfer of WAL file from theprimary to the standby|
|Previous:||From: Robert Haas||Date: 2009-07-03 02:16:41|
|Subject: Re: First CommitFest: July 15th|