Skip site navigation (1) Skip section navigation (2)

Re: logfile subprocess and Fancy File Functions

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: logfile subprocess and Fancy File Functions
Date: 2004-07-24 23:00:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
OK, let's go with something that is purely log stuff and we can revisit
in 7.6.  Ultimately I think we want postgresql.conf and pg_hba.conf to
be controllable perhaps at the SQL level rather than the function call
level so we need to scope the entire design for 7.6.  There is certainly
need for remote administration, and Andreas working on pgadmin is at the
front of that.

Andreas' original patch had code that processed the log file name and
threw it into a timestamp field in the function output.  If we are going
log-specific, it seems we should resurect that.

I have heard an idea that we could somehow allow SQL-level control over
pg_hba.conf and then dump the file rather than requiring manual editing,
and the same might be possible for other configuration files.


Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Agreed it should be relative to the log directory, which may or not be
> > under PGDATA, and don't let them go up above it.  Is there any downside
> > to allowing absolute reads as well because COPY can already read
> > absolute files.
> Perhaps not from a security point of view, but I think it would be
> rather bizarre for a general-purpose pg_read_file() function to default
> to reading from the log directory.  From the point of view of having
> a consistent API, it'd be better to call the functions something like
> pg_read_logdirectory() and pg_read_logfile() and restrict them to the
> log directory.  If we later decide we want to add a general
> pg_read_file() operation, we won't have to contort its operation to
> preserve compatibility with the log-fetching case.
> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-patches by date

Next:From: Claudio NatoliDate: 2004-07-25 01:32:12
Subject: Re: Pipe fixes for win32 services
Previous:From: Bruce MomjianDate: 2004-07-24 22:55:58
Subject: Re: logfile subprocess and Fancy File Functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group