| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: For review: Server instrumentation patch |
| Date: | 2005-07-25 14:37:07 |
| Message-ID: | 200507251437.j6PEb7q19230@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan wrote:
> It also just strikes me as just the wrong way to go about solving the
> apparent problem. If we want to make remote configuration or other
> operations possible, then instead of granting access to server resident
> files we should invent and implement an API that provides superusers the
> appropriate operations. For one thing, this would mean that if we ever
> decided to replace the current flat file system we use with something
> else we need not break clients that use the API. Just granting file
> access even if restricted to the data dir strikes me as a kludge.
I thought an API for postgresql.conf is what we agreed to, but I don't
see it on the TODO list. Is that correct?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2005-07-25 14:47:30 | Re: For review: Server instrumentation patch |
| Previous Message | Stephen Frost | 2005-07-25 14:31:51 | Re: For review: Server instrumentation patch |