On Thu, Jan 20, 2011 at 6:19 PM, Stephen Frost sfr...@snowman.net wrote:
Errr, well, ok, this is curious.
gis= alter user sfrost set role gis;
ALTER ROLE
gis= ^D\q
beren:/home/sfrost psql --cluster 8.4/main -d gis
psql (8.4.5)
Type help for help.
gis= show role;
role
--
gis
So
On Thu, Jan 20, 2011 at 08:55:42PM -0500, Daniel Farina wrote:
The problem is that running a reliable,
centralized LDAP service is not justifiable as compared to role
mangling on a per-node level, and the role mangling seems has some
shortcomings that are negotiable with gritted teeth.
On Fri, 2011-01-21 at 11:00 -0500, Garick Hamlin wrote:
I can't tell if PG supports querying a secondary RADIUS server?
I don't see how I would do it with the syntax here ...
http://developer.postgresql.org/pgdocs/postgres/auth-methods.html
Are multiple servers not supported?
Garick
Hello list,
I wanted to test the waters on how receptive people might be to an
extension that would allow Postgres to support two passwords for a
given role. I have recently encountered a case where this would be
highly useful when performing rolling password upgrades across many
client
On 01/20/2011 05:28 PM, Daniel Farina wrote:
Hello list,
I wanted to test the waters on how receptive people might be to an
extension that would allow Postgres to support two passwords for a
given role. I have recently encountered a case where this would be
highly useful when performing
On Thu, Jan 20, 2011 at 2:45 PM, Andrew Dunstan and...@dunslane.net wrote:
Have you thought of trying to use an external auth source like LDAP for such
a scheme?
I have thought about that, although LDAP is the only one that came to
mind (I don't know a whole lot of systems in detail, only by
Daniel Farina drfar...@acm.org writes:
I wanted to test the waters on how receptive people might be to an
extension that would allow Postgres to support two passwords for a
given role.
Not very. Why don't you just put two roles in the same group?
regards, tom lane
--
On Thu, Jan 20, 2011 at 3:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
I wanted to test the waters on how receptive people might be to an
extension that would allow Postgres to support two passwords for a
given role.
Not very. Why don't you just put two
How does this work with newly created objects? Is there a way to have
them default objects to a different owner, the parent of the two
roles?
No, but you could easily assign default permissions.
In the case of password rotation, the goal would be to
drop the old password after all clients
On Thu, Jan 20, 2011 at 4:35 PM, Josh Berkus j...@agliodbs.com wrote:
How does this work with newly created objects? Is there a way to have
them default objects to a different owner, the parent of the two
roles?
No, but you could easily assign default permissions.
In the case of password
* Eventual Retirement of old credentials without having to issue ALTER
statements (or really statements of any kind...) against application
schema objects.
OK, that's a different goal. You want to be able to expire passwords
with an overlap period. That's quite different from wanting an
On Thu, Jan 20, 2011 at 5:32 PM, Josh Berkus j...@agliodbs.com wrote:
* Eventual Retirement of old credentials without having to issue ALTER
statements (or really statements of any kind...) against application
schema objects.
OK, that's a different goal. You want to be able to expire
* Daniel Farina (drfar...@acm.org) wrote:
I have thought about that, although LDAP is the only one that came to
mind (I don't know a whole lot of systems in detail, only by name...so
suggestions welcome for low-administrative-overhead variants).
My preference is Kerberos and I find that it
On Thu, Jan 20, 2011 at 8:32 PM, Josh Berkus j...@agliodbs.com wrote:
* Eventual Retirement of old credentials without having to issue ALTER
statements (or really statements of any kind...) against application
schema objects.
OK, that's a different goal. You want to be able to expire
* Robert Haas (robertmh...@gmail.com) wrote:
It strikes me that it would be useful to have a GUC that sets the
owner of any new objects you create (much as you can control their
default schemas using search_path).
There was a great deal of discussion along these lines over the summer
of '09
On Thu, Jan 20, 2011 at 9:07 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
It strikes me that it would be useful to have a GUC that sets the
owner of any new objects you create (much as you can control their
default schemas using search_path).
There
On Thu, Jan 20, 2011 at 6:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 20, 2011 at 9:07 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
It strikes me that it would be useful to have a GUC that sets the
owner of any new objects you create
On Jan21, 2011, at 03:03 , Robert Haas wrote:
It strikes me that it would be useful to have a GUC that sets the
owner of any new objects you create (much as you can control their
default schemas using search_path). Obviously, you'd need to restrict
it so that it wouldn't allow you to create
On Jan21, 2011, at 03:14 , Daniel Farina wrote:
On Thu, Jan 20, 2011 at 6:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 20, 2011 at 9:07 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
It strikes me that it would be useful to have a GUC
* Daniel Farina (drfar...@acm.org) wrote:
On Thu, Jan 20, 2011 at 6:12 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not likely to write a patch for it, but if someone else writes one
I would be willing to (a) support it and (b) subject to consensus,
commit it.
Wouldn't this require a
20 matches
Mail list logo
