Re: Admin functions contrib

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 29 July 2004 18:41
> To: Andreas Pflug
> Cc: Bruce Momjian; PostgreSQL Patches; Dave Page
> Subject: Re: [PATCHES] Admin functions contrib
>
> Andreas Pflug <pgadmin(at)pse-consulting(dot)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.

pgAdmin I used to create helper functions and views on the server, and
not only were they a *real* pain in the neck to manage, but they were
also the most often complained about 'feature' of pgAdmin, to the extent
that when pgAdmin II was written, rule number #1 was 'it must offer 100%
functionality on a clean, standard database with no server side
objects'. In pga1 it even got to the stage that I wrote a cleanup wizard
to allow ppl to remove the stuff that was created. We also had problems
with people who had limited access to their servers (because they were
ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for
the postgresql.org sites for example - I can't imagine the response I'd
get if I asked for pl/perlu!!

This is primarily why we want to get the functionality into the backend.
Secondary to that, it will also allow phpPgAdmin and other tools to
offer the same functionality. It could be argued of course, that a
contrib module violates our standard database rule (which it does), but
it does at least allow us to get some standard code into the
distribution, in a way that /might/ be compatible with the feature
freeze, with a view to full integration in the next cycle. As Bruce has
seen, this is some pretty nice functionality that Andreas has added to
pga3, and is one of the few areas that we lag behind SQL Server etc. in
on the management front.

Regards, Dave.