It's better than no patch I think.


-----Original Message-----
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
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

Andreas is asking.


Dave Page wrote:
> > -----Original Message-----
> > From: Tom Lane [mailto:[EMAIL PROTECTED] 
> > Sent: 29 July 2004 18:41
> > To: Andreas Pflug
> > Cc: Bruce Momjian; PostgreSQL Patches; Dave Page
> > Subject: Re: [PATCHES] Admin functions contrib 
> > 
> > Andreas Pflug <[EMAIL PROTECTED]> 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                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to