Andreas Pflug wrote:
> > 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.
Well, if plperlu was always compiled by default we would be OK. If it
isn't then you are right it would be a problem. I see the --with-perl
option to configure so you are right it might be a problem.
Basically I think we are converging on an answer that we can't do any of
this for 7.5. The scope has gone way beyond what we had at feature
freeze, and we can't even get it to work on Win32, which was one of the
big goals for easier Win32 administration, so I think we should just
shelve all this and get it right for 7.6 when we have time to address
this.
I have added this to the TODO list:
* Allow server logs to be read using SQL commands
* Allow server configuration parameters to be modified remotetly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
