Skip site navigation (1) Skip section navigation (2)

Re: Open 7.3 items

From: Ron Snyder <snyder(at)roguewave(dot)com>
To: 'Bruce Momjian' <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Open 7.3 items
Date: 2002-07-31 21:29:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> As for 7.3, maybe we can get that done in time of everyone 
> likes it.  If
> we can't, what do we do?  Do we re-add the secondary password 
> file stuff
> that most people don't like?   My big question is how many other
> PostgreSQL users figured out they could use the secondary 
> password file
> for username/db restrictions?  I never thought of it myself.  Maybe I
> should ask on general.

Unless I'm misunderstanding you, we use it and like it.  We have several
servers on one machine that all access the same password file (we have it
softlinked).  If we need to create a user that accesses only one cluster,
then they get added to the file and created in the specific cluster.  If
that user then needs access to a different cluster, they just need to be
added to the new cluster.

The reason this is beneficial for us is because we then have the ability to
have postgres only user accounts, as well as accounts from YP.  When the YP
user changes their unix password in YP, their postgres db account password
changes as well (via cronjob).

There are fewer passwords for them to manage in this way, but we still get
the benefit of greater separation between clusters.

Let me know if you want more information about how we use it (or if I
misunderstood).  What is it that people _don't_ like?



pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-07-31 21:30:16
Subject: Re: Trim the Fat (Was: Re: Open 7.3 items )
Previous:From: Bruce MomjianDate: 2002-07-31 21:22:22
Subject: Re: Open 7.3 items

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group