Skip site navigation (1) Skip section navigation (2)

Re: Admin functions contrib

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Admin functions contrib
Date: 2004-07-31 04:33:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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

Andreas is asking.


Dave Page wrote:
> > -----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 to install pl/pgsql for
> the 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?

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-07-31 04:41:27
Subject: Fix for initdb translation
Previous:From: Tom LaneDate: 2004-07-31 00:52:27
Subject: Re: win32 timezone map

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group