Re: Admin functions contrib

Bruce Momjian wrote:
> I talked to Tom about this today. First, I want to apologize for
> running you around in circles in this. I don't think we are giving it
> the attention it needs because of our schedule. I also think the
> functionality is drifting into the "new features" territory and this is
> also part of the delay you are seeing.
>
> I think you did a great thing by breaking the patch into two parts: one
> for logging, and the other for log reading and other stuff. The logging
> part is already in the patch queue. As for the function below, I first
> think the security issue brough up about them wasn't a valid concern
> because as I stated someone could just load the plperl server-side
> language and do anything to the OS.
>
> In fact this might be the best solution for you. Instead of trying to
> code read/write/rename/unlink and other functions into the backend as
> hardcoded, why not just have pgadmin load plperlu and as the super-user
> you have access to that functionality, and much more, especially with
> the new plperl in 7.5. In fact, your goal of modifying the
> postgresql.conf file is much more natural in perl than in the API you
> supplied, and probably more reliable.
>
> So, I suggest we get the logging code into the backend, and you can code
> anything you want pgadmin to do in plperlu, and Win32 supports plperlu
> too. The big advantage is that you can improve the plperlu functions
> with every release of pgadmin.

I do not agree on this. Administrative tools should require as few
additional backend packages as possible. What you're proposing is simply
a nightmare. Actually, IMHO all functions should be *backend* code, not
contrib code, even less arbitrary loadable language functions. Certainly
an external package relying on a loadable language is quite the
opposite, generating lots of support issues. It won't generate trust if
pgadmin documentation advises "install untrusted plperl to maintain your
machine".
Additionally, several of the functions are by no means new, but
replacements, did you notice pg_xxx_size? I posted this stuff as contrib
module to keep it off the feature freeze issue. If it still can't go
there, it must stay an external module which will be distributed as
pgadmin add-on. Reimplementing it as plperlu is crap.

Regards,
Andreas