* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 3/5/15 2:17 PM, Stephen Frost wrote: > >* Jim Nasby (jim.na...@bluetreble.com) wrote: > >I'm all for it, though I would ask that we provide a way for superusers > >to delegate the ability to reset locked accounts to non-superusers. > > > >I'd want to think about it a bit more before settling on using pg_authid > > I guess it's a question of how durable we want it to be. We could > conceivable keep it in shared memory and let it wipe on a crash. > > But we already have code that ignores MVCC on a catalog table (IIRC > for updating pg_class stats after vacuum) so the pattern is there. I > don't see that we need more sophistication than that...
I'm not sure we should jump to that immediately.. > >to track the data. In any case, I do think we need a way to disable > >this ability for certain roles > > In the interest of something for this release... do we really need > that? My thought is we just special-case the postgres user and be > done with it. Though, if there's some other way to reset an account > from the shell, no need to even special case postgres. I don't think this is going to happen for 9.5 unless someone shows up with code in the *very* short term.. Further, realistically, we would want to design this properly and not just hack something together. > Though, I guess if we just follow the normal GUC behavior of > allowing per-database and -user overrides it wouldn't be that hard. Yes, using the GUC-based approach would allow users to be excluded from an overall (or per-database) policy. Thanks, Stephen
signature.asc
Description: Digital signature