This logging issue has drained a lot of time during feature freeze when
we should be getting existing patches in and completed.
I am willing to apply a perfect patch but I am not willing to spend
anymore time on this than I have to. This is all something that
shouldn't be happening during featur
Tom Lane wrote:
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.
I'm slightly worried that we might be painting ourselves into a corner,
ie implementing functionality that will never work on Windows.
>> 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.
I'm slightly worried that we might be painting ourselves into a corner,
ie implementing functionality that will never work on Windows.
Person
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 lo
Peter Eisentraut wrote:
Bruce Momjian wrote:
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.
How is logging typically handled on Windows?
It is done using the eventlog service (which is supported as
Bruce Momjian wrote:
> 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.
How is logging typically handled on Windows?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
--
Bruce Momjian wrote:
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.
Please commit ASAP. Is I stated several times, I'll do the win32 as soon
as I get a chance to. It's not a logge
-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 <[EMA
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Fri 7/30/2004 5:34 PM
To: Dave Page
Cc: Tom Lane; Andreas Pflug; PostgreSQL Patches
Subject: Re: [PATCHES] Admin functions contrib
> Ouch, that is a powerful argument! The big problem is that we are
> des
Dave Page wrote:
> > 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 fu
Andreas Pflug wrote:
> Dave Page wrote:
>
> > 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.
> >
>
> If you're curious what Bruce has seen, it was this:
Dave Page wrote:
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.
If you're curious what Bruce has seen, it was this:
http://www.pse-consulting.de/pgadmin3/pgadmi
> -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]> w
Bruce Momjian wrote:
If it's not going into the distribution as contrib or core, I'll package
that as additional admin pack. I'm quite sure I can convince the win32
installer packager guys to include that as default-on option as soon as
I'm able to prove them how it's working.
Uh, but it isn't
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 eve
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >
> > Basically I think we are converging on an answer that we can't do any of
> > this for 7.5.
>
> If it's not going into the distribution as contrib or core, I'll package
> that as additional admin pack. I'm quite sure I can convince the win32
Bruce Momjian wrote:
Basically I think we are converging on an answer that we can't do any of
this for 7.5.
If it's not going into the distribution as contrib or core, I'll package
that as additional admin pack. I'm quite sure I can convince the win32
installer packager guys to include that as d
Andreas Pflug 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 agr
Bruce Momjian wrote:
I talked to Tom about this today. First, I want to apologize for
running you around in circles in this. I don't think we are giving it
the attention it needs because of our schedule. I also think the
functionality is drifting into the "new features" territory and this is
als
I talked to Tom about this today. First, I want to apologize for
running you around in circles in this. I don't think we are giving it
the attention it needs because of our schedule. I also think the
functionality is drifting into the "new features" territory and this is
also part of the delay
These files add administrative functions to pgsql 7.5. All are used by
pgAdmin3 or will be used in the near future if available. This is meant
as contrib module, whilst IMHO all these functions should be integrated
into the backend.
Included are functions to
log file access
These where previous
21 matches
Mail list logo