Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: pgadmin-hackers-owner@postgresql.org
>>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of
>>Andreas Pflug
>>Sent: 28 August 2005 21:48
>>To: pgadmin-hackers
>>Subject: [pgadmin-hackers] pgsql 8.1 instrumentation status
>>
>>I've been testing the current status of instrumentation function
>>integration in pgsql8.1 and found the result quite frustrating.
>
>
> We should talk more - I've been looking at that! (thought you were on
> Slony).
Yes, but need those functions to work with logfiles etc.
>
>>All other functions are either omitted completely, or
>>stripped down to
>>near or complete unusability:
>>The file functions, if present at all, don't accept absolute
>>paths, even
>>if the log directory is addressed. pg_read_file isn't a
>>replacement for
>>
>>pg_file_read for this reason.
>
>
> No, just hit that. We knew absolute paths outside the data dir were
> going to be rejected, but they seem to have gone further. They should be
> allow if:
>
> 1) The path starts with $PGDATA
> 2) The path exactly matches one of the config files.
logfiles may go somewhere else too.
>
> I would call this a bug. If you've got time to produce a simple patch,
> I'll try to argue it in.
I won't. A perfectly working and tightly restricted version is available
for more than a year now.
>
>>pg_ls_dir lost its second bool parameter.
>>
>>pg_stat_file isn't implemented, although announced by Bruce.
>>This makes
>>pg_file_length impossible.
>
>
> Yes it is. I've just been using it. Don't forget, Tom made it into a
> procedure to allow things like SELECT
> (pg_file_stat('pg_hba.conf')).size; to work
'k. pg_file_length may use it.
> No, only write, unllink and rename should now be needed, with a suitable
> patch to fix the path issue.
pg_logdir_ls...
I won't duplicate pgsql's formatting/interpreting code in pgadmin.
>>PS AFAICS we now could add pg_terminate_backend safely too, IIRC the
>>on-exit lock tables cleanup is corrected now.
>
>
> I'm pretty sure we won't argue that one in now. I think Tom will demand
> more proof of proper testing.
I'm certainly not talking about arguing to commit this to core, but to
support this in our package, which will be needed anyway, e.g. for
pg_logdir_ls.
Regards,
Andreas