| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz> |
| Cc: | Sean Chittenden <sean(at)chittenden(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PGBugs List <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: ALTER USER SET log_* not allowed... |
| Date: | 2004-11-10 16:41:35 |
| Message-ID: | 13364.1100104895@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz> writes:
> The current functionality could be useful inside particular code paths
> of an application, where you want to increase the log verbosity in a
> particular part of the code, when it (unpredictably) happens, without
> nuking the logs entirely.
> Of course you are superuser when you review such logs, but I wouldn't
> usually want the db connection from the application to have to run as
> superuser if I could help it... especially not a web application.
Sure. There is a workaround for that though, which is to provide a
SECURITY DEFINER function for the app to call that will adjust the
logging level for it, rather than trying to do the SET directly in
unprivileged code.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-11-10 16:53:18 | Re: ALTER USER SET log_* not allowed... |
| Previous Message | Stefano Tazzi | 2004-11-10 15:57:37 | PostgreSQL 8 Installed on Windows |