Alvaro Herrera <[EMAIL PROTECTED]> writes:
> No other object type has the ability to require you to stop the server
> and start a standalone backend to fix the mistake, which is what makes
> this thing unique.
This one doesn't either. I already pointed out two reasons why not:
1. you can connect
On Tue, 2006-04-25 at 08:53 -0400, Alvaro Herrera wrote:
> Gevik Babakhani wrote:
> My point is that the behavior you describe is broken. The warning
> should be issued but the command should be executed anyway. That way
> the user executing it knows that he has locked everyone out of the
> data
Stephen Frost wrote:
> * Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> > Gevik Babakhani wrote:
> > > On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote:
> > > > Why are we debating this? It won't get accepted anyway, because the
> > > > whole thing is silly. Show me one other object type that we is
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> Gevik Babakhani wrote:
> > On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote:
> > > Why are we debating this? It won't get accepted anyway, because the
> > > whole thing is silly. Show me one other object type that we issue
> > > such warnings for, or
Gevik Babakhani wrote:
> Hi
>
> On Mon, 2006-04-24 at 23:07 -0400, Alvaro Herrera wrote:
> > Gevik Babakhani wrote:
> >
> > > If one is going to revoke the last ACL_CONNECT, a warning is going to
> > > issued then that part of the REVOKE gets canceled.
> >
> > Humm, no, the WARNING is issued bu
Gevik Babakhani wrote:
> On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote:
> > Why are we debating this? It won't get accepted anyway, because the
> > whole thing is silly. Show me one other object type that we issue
> > such warnings for, or anyone else who has even suggested that we should.
N
On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote:
> Why are we debating this? It won't get accepted anyway, because the
> whole thing is silly. Show me one other object type that we issue
> such warnings for, or anyone else who has even suggested that we should.
So, I am very much confused. Wha
Hi
On Mon, 2006-04-24 at 23:07 -0400, Alvaro Herrera wrote:
> Gevik Babakhani wrote:
>
> > If one is going to revoke the last ACL_CONNECT, a warning is going to
> > issued then that part of the REVOKE gets canceled.
>
> Humm, no, the WARNING is issued but the REVOKE is executed anyway.
I have
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gevik Babakhani wrote:
>> If one is going to revoke the last ACL_CONNECT, a warning is going to
>> issued then that part of the REVOKE gets canceled.
> Humm, no, the WARNING is issued but the REVOKE is executed anyway.
Why are we debating this? It won
Gevik Babakhani wrote:
> If one is going to revoke the last ACL_CONNECT, a warning is going to
> issued then that part of the REVOKE gets canceled.
Humm, no, the WARNING is issued but the REVOKE is executed anyway.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
P
Hi,
The following is also added to a new patch.
> > At this moment the owner of the database CAN REVOKE himself form the
> > ACL_OBJECT_DATABASE. If the implementation above is acceptable then I
> > can work on this one :)
>
> Hmm, what do you want to do about it? ISTM the owner should be able
> Ok, good. This is what people was aiming for initially, I hope. What
> do people think, particularly those who wanted to manage pg_hba.conf via
> SQL commands?
I guess for this one more people have to play with the new
functionality.
> Without looking at the surrounding code, I'm a bit wary
Hi
> I don't understand. The code should look like this:
>
> if (acl in pg_database == NULL)
> acl = acldefault
> else
> acl = acl in pg_database
> if (has_permission(acl, user, ACL_CONNECT))
> can connect
> else
> can't connect
>
To my surprise the code you described a
Gevik Babakhani wrote:
> To my surprise the code you described above was already there :)
> function aclchk.c:pg_database_aclmask:1696
Sure, that sort of was my point :-)
> If the above is okay and correct. Then I guess for simple systems one
> could only enter the line below in pg_hba.conf
>
14 matches
Mail list logo