Zdenek Kotala wrote:
> Kohei KaiGai napsal(a):
>> It seems to me some of SE-PostgreSQL patches are not delivered yet,
>> although [3/4] and [4/4] were already done.
>>
>> Does anti-spam system caught my previous three messages?
>> If necessary, I will send them again.
>
> There is a file size limi
[2/4] - sepostgresql-sepgsql-8.4devel-3.patch.gz
This patch provides SE-PostgreSQL facilities based on PGACE.
Security-Enhanced PostgreSQL (SE-PostgreSQL) is a security extension
built in PostgreSQL, to provide system-wide consistency in access
controls. It enables to apply a single unigied secur
Kohei KaiGai napsal(a):
> It seems to me some of SE-PostgreSQL patches are not delivered yet,
> although [3/4] and [4/4] were already done.
>
> Does anti-spam system caught my previous three messages?
> If necessary, I will send them again.
There is a file size limitation. If your patch is too bi
[1/4] - sepostgresql-pgace-8.4devel-3.patch.gz
This patch provides PGACE (PostgreSQL Access Control Extension) framework.
It has a similar idea of LSM (Linu Security Module).
It can provide a guest module several hooks at strategic points.
The guest module can make its decision whether required a
I've submitted 5 patches in Jan/Feb, none of which appear on the patch
status page for the CommitFest, or any other status page I'm aware of.
There *is* a comment on that page about "Minor Recovery..." which was a
patch from me that was committed to 8.3 on 26 Sep 2007, so that item can
be removed f
On Sun, Mar 16, 2008 at 10:53:02PM -0400, Tom Lane wrote:
> Kenneth Marshall <[EMAIL PROTECTED]> writes:
> > Dear PostgreSQL Developers,
> > This patch is a "diff -c" against the hashfunc.c from postgresql-8.3beta1.
>
> It's pretty obvious that this patch hasn't even been tested on a
> big-endian
Alvaro Herrera wrote:
Kohei KaiGai wrote:
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it
I'll submit the proposal of SE-PostgreSQL patches again, because some of
previous
messages are filtered due to attachment and I cannot provide whole of patches
yet.
Please refer the pointed URL, as follows.
--
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-Postgr
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
>> Before we go any further, is this work derived from SELinux? If so, is
>> it covered under the GPL? If so, can it be licensed under BSD terms?
>
> All of SE-PostgreSQL works are licensed unser BSD terms.
> We are considering to push SE-PostgreSQL in
Kohei KaiGai wrote:
> The series of patches are the proposal of Security-Enhanced PostgreSQL
> (SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD terms?
All of SE-PostgreSQL works are licensed unser BSD terms.
We are considering to push SE
Am Donnerstag, 6. März 2008 schrieb Tom Lane:
> I attach a proposed patch against HEAD for this. It's a bit long
> but most of the bulk is refactoring eqsel() to make it easy to use from
> prefix_selectivity(). The intellectual content is just in the last
> diff hunk.
Looking at the patch as com
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> [ patch to reduce probability of deadlock of CREATE INDEX CONCURRENTLY
> with other things ]
This patch no longer applies because of the VirtualXid changes.
Looking at it again, I'm fairly dissatisfied with it anyway;
I really don't like moving the
Well, this all seemed like work-in-progress stuff so it wasn't being
tracked. If you have things that need to be reviewed/applied, I suggest
you resubmit and mark them as ready.
As far as the doc patch, I see that as applied by Tom:
revision 2.113
date: 2008/01/23 20:21:37; aut
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 6. März 2008 schrieb Tom Lane:
>> I attach a proposed patch against HEAD for this. It's a bit long
>> but most of the bulk is refactoring eqsel() to make it easy to use from
>> prefix_selectivity(). The intellectual content is just in
KaiGai,
> The series of patches are the proposal of Security-Enhanced PostgreSQL
> (SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Since I'm (Finally!) expecting the TrustedSolaris folks to put some work into
PostgreSQL as well this year, I'm going to ask them to look over P
On Mon, 2008-03-17 at 12:54 -0400, Bruce Momjian wrote:
> Well, this all seemed like work-in-progress stuff so it wasn't being
> tracked. If you have things that need to be reviewed/applied, I suggest
> you resubmit and mark them as ready.
OK thanks, will do.
> As far as the doc patch, I see th
Am Donnerstag, 6. März 2008 schrieb Robert Lor:
> Attached is the updated patch which addressed all the concerns from
> Peter and Tom.
>
> * The header file containing the probe macros is now included only in
> the .c files that need it.
> * All probe macro names now start with TRACE_ (eg:
> TRACE_
NikhilS <[EMAIL PROTECTED]> writes:
> As per discussion on -hackers, a patch which allows updates to use
> subselects is attached with this mail.
I looked over this patch briefly, and I'm afraid it still needs a lot of
work.
The way you altered transformUpdateStmt is a mess; it's duplicating
logi
I wrote:
> ... eg backend/nodes/, optimizer/util/clauses.c, ruleutils.c...)
Actually, on further thought ruleutils.c represents one of the biggest
stumbling blocks here. We have to be able to reverse-compile the parse
tree into something that's at least semantically equivalent to the
original que
Here is the proposed patches. If there's no objection, I will
commit(or Shall I wait for next "commit festa"?).
Note that I decide to use lo_import_with_oid, but the signature is
changed(the second and the third arguments are swapped because it
seems more natural).
--
Tatsuo Ishii
SRA OSS, Inc. Ja
Tom,
Thanks for your comments and for your work incorporating our patch into
8.4. This will help us provide even a better patch next time around :)
-Shreya Bhargava and Tom Raney
Tom Raney <[EMAIL PROTECTED]> writes:
This revised version of our patch uses the function estimate_rel_size()
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Here is the proposed patches. If there's no objection, I will
> commit(or Shall I wait for next "commit festa"?).
No need to wait IMHO.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To m
23 matches
Mail list logo
