Re: A modest proposal: get rid of GUC's USERLIMIT
От | Bruce Momjian |
---|---|
Тема | Re: A modest proposal: get rid of GUC's USERLIMIT |
Дата | |
Msg-id | 200411120405.iAC455S15625@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: A modest proposal: get rid of GUC's USERLIMIT (Andrew McMillan <andrew@catalyst.net.nz>) |
Ответы |
Re: A modest proposal: get rid of GUC's USERLIMIT
|
Список | pgsql-hackers |
Andrew McMillan wrote: -- Start of PGP signed section. > On Wed, 2004-11-10 at 11:45 -0500, Tom Lane wrote: > > Andrew McMillan <andrew@catalyst.net.nz> writes: > > > When tracking down gnarly problems in heavily multi-user applications > > > enabling higher log levels at selective points has the potential to help > > > _a lot_ with diagnostic detail, without smothering you in _every_ > > > detail. > > > > Sure. As I pointed out in the other thread, if you want to allow an app > > to do this, you can make available a SECURITY DEFINER function that > > performs the desired SET on its behalf. By setting execute permissions > > on the function and/or including restrictions in the function's code, > > you can make this as tight or as loose a loophole as you like. So it's > > certainly possible to do what you want in any case. I think the issue > > at hand is what's appropriate to provide as hard-wired functionality. > > That sounds excellent - I hadn't realised that this workaround would be > possible, and indeed with this in place that will provide even better > control over the facility. OK, here is one vote for the ALTER USER/remove USERLIMIT croud, and you were the person who originally mentioned the problem. You don't think the function creation is hard. Perhaps that's the way to go then. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: