Re: For review: Server instrumentation patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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:51:35
Message-ID: 27690.1122303095@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I still think, security considerations aside, that an API for config
> settings would be a much better piece of design than providing file
> system access functions.

I agree with that. Given what we currently have, though, remote config
and remote log examination do require filesystem access. But IMHO
there's no very good reason why admin actions requiring filesystem
access shouldn't be programmed in an untrusted PL, rather than through
separate file-access functions. Andreas argued that he didn't want to
make pgAdmin functionality dependent on the availability of an untrusted
PL, but I think that argument is bogus. If the admin doesn't want to
install an untrusted PL for pgAdmin to use, why in the world would he
be happy with equivalent functionality being installed in such a way
that he can't get rid of it?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2005-07-25 14:54:54 Re: For review: Server instrumentation patch
Previous Message Magnus Hagander 2005-07-25 14:47:30 Re: For review: Server instrumentation patch