Re: Admin functions contrib - Mailing list pgsql-patches

It's better than no patch I think.

/D


-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Sat 7/31/2004 5:33 AM
To: Dave Page
Cc: Tom Lane; Andreas Pflug; PostgreSQL Patches
Subject: Re: [PATCHES] Admin functions contrib


Do people want the server file logging/rotating patch applied if it is
Unix-only?  Right now the patch is ifdef'ed so Win32 use of it is
disabled.

Andreas is asking.

---------------------------------------------------------------------------

Dave Page wrote:
>
>
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl@sss.pgh.pa.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@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.
>
> 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html
>

--
  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