Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I don't think GRANT CONNECT fits into our setup at all. I also doubt
> > that it will be needed very much once we have schemas.
>
> People have many times asked for a way to alter the connection settings
> from within the database. For instance,
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I don't know. Automatically modifying a manually maintained config file
> > isn't too common a feature. One problem would be if you where modifying
> > the file in your editor and the backend rewrote the file.
>
> That's not different from
Bruce Momjian writes:
> I don't know. Automatically modifying a manually maintained config file
> isn't too common a feature. One problem would be if you where modifying
> the file in your editor and the backend rewrote the file.
That's not different from you modifying the file in your editor
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I don't think GRANT CONNECT fits into our setup at all. I also doubt
> > that it will be needed very much once we have schemas.
>
> People have many times asked for a way to alter the connection settings
> from within the database. For instance,
Tom Lane writes:
> I don't think GRANT CONNECT fits into our setup at all. I also doubt
> that it will be needed very much once we have schemas.
People have many times asked for a way to alter the connection settings
from within the database. For instance, you add users in the database,
but th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Unfortunately, that would give us two places to specify
> > the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem?
>
> Yes. What if they conflict?
>
> I don't think GRANT CONNECT fits into our setup at all. I als
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Unfortunately, that would give us two places to specify
> the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem?
Yes. What if they conflict?
I don't think GRANT CONNECT fits into our setup at all. I also doubt
that it will be needed
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I have another idea. What if we had a default group for each database,
> > like pg_connect_{dbname}, and you can add/remove users from that group
> > to grant/remove connection privileges?
>
> That strikes me as a very ugly abuse of the priv
Bruce Momjian writes:
> I have another idea. What if we had a default group for each database,
> like pg_connect_{dbname}, and you can add/remove users from that group
> to grant/remove connection privileges?
That strikes me as a very ugly abuse of the privilege system. If you want
to grant a
pgman wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > I am adding users and groups to pg_hba.conf.
> >
> > You know what would be cool?
> >
> > GRANT CONNECT ON mydb TO GROUP myfriends;
> >
> > and it rewrites pg_hba.conf accordingly.
> >
> > Just a thought...
>
> We are
Bruce Momjian wrote:
>
> Now, as far as rewriting pg_hba.conf, that goes into an area where we
> are not sure if the master connection information is in the file or in
> the database. We also get into a chicken and egg case where we have to
> have the database loaded to connect to it. I am inte
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I am adding users and groups to pg_hba.conf.
>
> You know what would be cool?
>
> GRANT CONNECT ON mydb TO GROUP myfriends;
>
> and it rewrites pg_hba.conf accordingly.
>
> Just a thought...
We are actually not that far away. If you crea
Bruce Momjian writes:
> I am adding users and groups to pg_hba.conf.
You know what would be cool?
GRANT CONNECT ON mydb TO GROUP myfriends;
and it rewrites pg_hba.conf accordingly.
Just a thought...
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem is when to retokenize pg_hba.conf after a new pg_group is
> > made. Seems I can either force administrators to 'pg_ctl reload' to
> > update for group changes, or automatically retokenize pg_hba.conf every
> > time I upda
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, that was the issue. We tell people pg_hba.conf only gets reloaded
> > when they tell the postmaster to do it. We can't have it happening at
> > random times, e.g. password change.
>
> I agree on that: the signal should cause t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, that was the issue. We tell people pg_hba.conf only gets reloaded
> when they tell the postmaster to do it. We can't have it happening at
> random times, e.g. password change.
I agree on that: the signal should cause the postmaster to reload
pg_p
Ross J. Reedstrom wrote:
> On Thu, Mar 21, 2002 at 11:38:05AM -0500, Bruce Momjian wrote:
> >
> > I am handling it like pg_shadow. The problem is that because I expand
> > pg_group inside the pg_hba tokens, I have to retokenize pg_hba.conf too
> > after pg_group changes. I assumed we didn't want
I think I have figured out a way to do this efficiently. Instead of
making pg_group with groupname/username on each line, I will do
groupname/username,username, ... so I can spin through the group token
file much quicker; that way, I can read just retokenize pg_group and
spin through it for eac
18 matches
Mail list logo
