Dave Page wrote:
>>From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
>>Sent: 29 August 2005 10:21
>>To: Dave Page
>>Subject: Re: [pgadmin-hackers] pgsql 8.1 instrumentation status
>>I won't implement date interpretation in the client, full stop.
> Seriously Andreas, you need to get over this annoyance about these
> functions not getting in as is. It's not healthy, and is only hurting
> you and the end users who might miss out on features. I realise the end
> result wasn't exactly what you wanted, but sometimes we just have to
> compromise, otherwise we won't get anywhere at all.
> Please, let's move on and make things work with what we have.
>>You, as well as all others complaining about pg_logdir_ls, fail to
>>explain how a query like
>>select pg_file_unlink(filename) FROM pg_logdir_ls
>>where filetime < now() - '10 days'::interval
>>should work reliably. Try it with an alternate implementation, in the
>>presence of "bizarre filenames"!
> There are various reasons for this, including:
> - None of our code does that, so it is a non-issue at the moment.
> - There is no pg_file_unlink in the server, so why should the
> pgsql-hackers care about making it easy to use?
This condenses the problem. They don't care.
> - pg_logdir_ls only worked with log_filename set to a specific value.
> You know as well as anyone that this is not good software design.
I never intended to open this to configuration. MSSQL doesn't offer this
> - Virtually identical results can be achieved using ctime or mtime from
> pg_stat_file with pg_dir_ls (as I think Bruce suggested).
No, not reliably. See the archives.
> If you are not happy with this, please let me know and I will fix the
> logfile viewer for 8.1.
This is not fixing, this is working around.
pg_logdir_ls works reliably or not at all, if you take the break option
(editing log_filename). All other proposals can be damaged in less
>>This logfile configuration stuff is a bummer. Anybody who changes it
>>will probably use his own logfile reader.
> Possibly, but not necessarily. What about people who rotate their logs
> daily for example? They might simply want to lose the unnecessary
> characters from the filenames.
Which would be really short sighted, and is error prone. When max
logfile size is reached, those people will be bitten.
>>I'll be committing a 8.1 version of the admin package soon,
>>which may be
>>switched over step by step to use core functions if applicable. For
>>now, most of them do not deliver the same functionality as
>>present for 8.0.
> I already created an 8.1 admin pack and committed it to SVN. Currently
> it contains rename, write and unlink. If we need to add more, I'd like
> it to be because we really have no choice to get sane functionality,
> rather than just because we would prefer something work slightly
Adapting the 8.0 admin package to 8.1 is much less effort than adapting
to the pgsql functions.
In response to
pgadmin-hackers by date
|Next:||From: Dave Page||Date: 2005-08-29 22:05:52|
|Subject: Re: pgsql 8.1 instrumentation status|
|Previous:||From: svn||Date: 2005-08-29 19:04:25|
|Subject: SVN Commit by dpage: r4426 - trunk/www/pgadmin3/cnt|