Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Bruce Momjian 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.
This argument doesn't really hold water when the alternative is a
contrib package. It's considerably more likely that the installation
will have plperl than that it will have some random contrib package.
Also, what happens if you find that the contrib package doesn't do
everything you need? You'll be stuck for another PG release cycle,
whereas rejiggering a plperl function that pgadmin is defining for
itself is no problem.
I think that developing with plperl for a few months would be a good
path, because then you would have some actual field experience under
your belt to justify the specific design of the contrib or core backend
functions you want. Right now they look mighty scattershot.
> It won't generate trust if pgadmin documentation advises "install
> untrusted plperl to maintain your machine".
Nonsense. You are already expecting these people to give you superuser
access, no? They had better trust you already. (Actually, you wouldn't
even have to ask them --- you could just create plperlu for yourself
--- but I suppose that would seem impolite.)
> I posted this stuff as contrib
> module to keep it off the feature freeze issue.
Contrib does not have an exception for the feature freeze rule. It's a
little looser maybe but that doesn't mean we'll accept an entire new
module after freeze.
> Reimplementing it as plperlu is crap.
I'm sorry you feel that way. It seemed like a fairly attractive
alternative to me, especially for early development.
regards, tom lane