> > 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.
For the record, me too. But I don't see that happening for 8.1,
considering the feature freeze and timescale...
> 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?
Not trying to speak for Andreas here, I see the problem as an added
dependency *outside* postgresql. If he were to use pl/perl, he couldn o
longer admin a postgresql server without perl on it (and perl installed
as a shared lib). Same for python and tcl - which I beleive rounds up
all the PLs.
Plus the admin will have to have included it in ./configure and run
createlang with it.
//Magnus
