It's better than no patch I think. /D
-----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 disabled. 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 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 [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
