Robert Haas wrote:
> On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> wrote:
> > On Mon, 27 Sep 2010 21:07:33 -0400
> > Robert Haas wrote:
> >> I found and fixed a few more issues and committed this. ?The pg_dump
> >> support had a few escaping bugs, and I added tab completion support
> >> for p
On Tue, Sep 28, 2010 at 3:22 PM, Robert Haas wrote:
> On Tue, Sep 28, 2010 at 8:03 AM, Peter Eisentraut wrote:
> > On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
> >> On Tue, Sep 28, 2010 at 13:50, Robert Haas
> wrote:
> >> > On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> >> >> Th
On Tue, Sep 28, 2010 at 11:14 AM, Tom Lane wrote:
> Robert Haas writes:
>> Another angle on this problem is that, at least AFAICT, the duplicate
>> OIDs are completely harmless so long as they are in different
>> catalogs. And if they are in the same catalog, then initdb will fail
>> (and shame
Robert Haas writes:
> Another angle on this problem is that, at least AFAICT, the duplicate
> OIDs are completely harmless so long as they are in different
> catalogs. And if they are in the same catalog, then initdb will fail
> (and shame on you if you don't notice that). Long, long ago
> pg_de
On tis, 2010-09-28 at 09:22 -0400, Robert Haas wrote:
> > I think it should actually be run as part of the regular build.
> Ever
> > since I started using git and developing like 10 features at once,
> and
> > other people doing the same, the chances of (hidden) OID conflicts
> is
> > growing imme
On Tue, Sep 28, 2010 at 8:03 AM, Peter Eisentraut wrote:
> On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
>> On Tue, Sep 28, 2010 at 13:50, Robert Haas wrote:
>> > On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
>> >> The src/include/catalog/duplicate_oids script reports that 3037 ~
>>
On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
> On Tue, Sep 28, 2010 at 13:50, Robert Haas wrote:
> > On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> >> The src/include/catalog/duplicate_oids script reports that 3037 ~
> >> 3040 are used two or more times.
> >>
> >> Though all regres
On Tue, Sep 28, 2010 at 13:50, Robert Haas wrote:
> On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> wrote:
>> On Mon, 27 Sep 2010 21:07:33 -0400
>> Robert Haas wrote:
>>> I found and fixed a few more issues and committed this. The pg_dump
>>> support had a few escaping bugs, and I added tab c
On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
wrote:
> On Mon, 27 Sep 2010 21:07:33 -0400
> Robert Haas wrote:
>> I found and fixed a few more issues and committed this. The pg_dump
>> support had a few escaping bugs, and I added tab completion support
>> for psql. Considering the size of the
On Mon, 27 Sep 2010 21:07:33 -0400
Robert Haas wrote:
> I found and fixed a few more issues and committed this. The pg_dump
> support had a few escaping bugs, and I added tab completion support
> for psql. Considering the size of the patch, it seems likely that
> there are some issues we both ov
On Mon, Sep 27, 2010 at 4:05 AM, KaiGai Kohei wrote:
>> Thanks, this looks like mostly good stuff. Here's a new version of
>> the patch with some bug fixes, additional regression tests, and other
>> cleanup. I think this is about ready to commit.
>
> Thanks for your reviewing and cleaning-up.
I
(2010/09/27 11:49), Robert Haas wrote:
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei wrote:
* The "dummy_esp" module and regression test for SECURITY LABEL statement.
This module allows only four labels: "unclassified", "classified",
"secret" and "top secret". The later two labels can be se
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei wrote:
> * The "dummy_esp" module and regression test for SECURITY LABEL statement.
> This module allows only four labels: "unclassified", "classified",
> "secret" and "top secret". The later two labels can be set by only
> superusers. The new regre
On Fri, Sep 24, 2010 at 8:54 AM, KaiGai Kohei wrote:
> (2010/09/24 20:56), Robert Haas wrote:
>>
>> 2010/9/23 KaiGai Kohei:
Please see
http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php
>>> OK, I'll emulate this approach at first.
>>
>> Don't worry about this par
(2010/09/24 20:56), Robert Haas wrote:
2010/9/23 KaiGai Kohei:
Please see http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php
OK, I'll emulate this approach at first.
Don't worry about this part - I will do this myself. If you can just
fix the pg_dump stuff, I think we will be
2010/9/23 KaiGai Kohei :
>> Please see http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php
>>
> OK, I'll emulate this approach at first.
Don't worry about this part - I will do this myself. If you can just
fix the pg_dump stuff, I think we will be in pretty good shape.
--
Robert H
(2010/09/24 11:53), Robert Haas wrote:
> 2010/9/23 KaiGai Kohei:
>>> Most of the contents of the new documentation section on external
>>> security providers seemed irrelevant to me, which I guess I can only
>>> blame myself for since I was the one who asked for that section to be
>>> created, and
Robert Haas writes:
> Perhaps. I know that in the past we have not documented hook
> functions, and I'm thinking that there may be people (in particular,
> possibly Tom) who have strong feelings about keeping it that way.
> Even if that's not the case, once we do start documenting the hooks,
> we
2010/9/23 KaiGai Kohei :
>> Most of the contents of the new documentation section on external
>> security providers seemed irrelevant to me, which I guess I can only
>> blame myself for since I was the one who asked for that section to be
>> created, and I didn't specify what it should contain all
Robert, thanks for your reviewing and revising.
(2010/09/23 13:28), Robert Haas wrote:
> On Thu, Sep 16, 2010 at 11:12 PM, Robert Haas wrote:
>> 2010/9/14 KaiGai Kohei:
>>> The attached patch is a revised version, but a bit difference from what
>>> I introduced yesterday.
>>
>> I am working throu
On Thu, Sep 23, 2010 at 2:06 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> The point is that SECURITY LABEL, as coded, will fail utterly unless
>> there is a label provider loaded. So you can't actually run it and
>> check the results in the catalog without loading a
* Robert Haas (robertmh...@gmail.com) wrote:
> The point is that SECURITY LABEL, as coded, will fail utterly unless
> there is a label provider loaded. So you can't actually run it and
> check the results in the catalog without loading a contrib module.
Urgh, yes, point. Well, we could test that
On Thu, Sep 23, 2010 at 10:21 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Most of the contents of the new documentation section on external
>> security providers seemed irrelevant to me, which I guess I can only
>> blame myself for since I was the one who asked for t
Robert,
First off, thanks alot for working on this. My apologies for not having
time to help out. A few minor comments:
* Robert Haas (robertmh...@gmail.com) wrote:
> Most of the contents of the new documentation section on external
> security providers seemed irrelevant to me, which I guess I
2010/9/14 KaiGai Kohei :
> The attached patch is a revised version, but a bit difference from what
> I introduced yesterday.
I am working through this patch and fixing a variety of things things
that seem to need fixing. Please hang tight and don't send any new
versions for now.
Thanks,
--
Rob
On Mon, Sep 13, 2010 at 8:38 AM, KaiGai Kohei wrote:
> Yes, if and when MAC-X and MAC-Y are installed, it is significant event
> for MAC-X to change X's label, so MAC-X may need to check special
> permissions. But it is a common event for MAC-Y and DAC, so they checks
> an appropriate permission t
(2010/09/13 20:46), Robert Haas wrote:
2010/9/13 KaiGai Kohei:
Robert, although you suggested that only one ESP module shall be
invoked on relabeling an object before, and I agreed this design
at that time, but I noticed that we cannot implement the following
behavior correctly.
SELinux defines
2010/9/13 KaiGai Kohei :
> Robert, although you suggested that only one ESP module shall be
> invoked on relabeling an object before, and I agreed this design
> at that time, but I noticed that we cannot implement the following
> behavior correctly.
>
> SELinux defines these permissions correspondi
Robert, although you suggested that only one ESP module shall be
invoked on relabeling an object before, and I agreed this design
at that time, but I noticed that we cannot implement the following
behavior correctly.
SELinux defines these permissions corresponding to table relabeling.
- db_table:{
29 matches
Mail list logo
