Re: CVS Commit by dpage: log_filename is only in 8+ - Mailing list pgadmin-hackers

From Dave Page
Subject Re: CVS Commit by dpage: log_filename is only in 8+
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E41A79B9@ratbert.vale-housing.co.uk
Whole thread Raw
In response to CVS Commit by dpage: log_filename is only in 8+  (cvs@cvs.pgadmin.org)
Responses Re: CVS Commit by dpage: log_filename is only in
List pgadmin-hackers

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 05 September 2004 18:18
> To: pgadmin-hackers@postgresql.org; Dave Page
> Subject: Re: [pgadmin-hackers] CVS Commit by dpage:
> log_filename is only in 8+
>
> cvs@cvs.pgadmin.org wrote:
> > Log Message:
> > -----------
> > log_filename is only in 8+
>
> No need to check this here; it's already done in frmStatus.

Well it wasn't working then as it barfed when I ran on 7.3. Though if
you look more closely at the patch, you'll see that I was restricting
the SHOW logfilename; query to 8+.

> Additionally, pgadmin3 shouldn't bother about logfilename
> formats known to the backend; this might change any time.

Yes, it might - and if it does, pg_logdir_ls will fail gracefully with
an error because it can't parse the timestamp - and even if we made it
much more clever, there are still a million and one formats in which we
won't be able to figure out the timestamp. The reason pgAdmin does this
check is so that we a) only do it once and b) we can hide the log tab in
the same way as we do if pg_logdir_ls doesn't exist.

Regards, Dave.

pgadmin-hackers by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: MacosX No rule to make target `ui/common/*.xrc',
Next
From: Andreas Pflug
Date:
Subject: Re: CVS Commit by dpage: log_filename is only in