Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
This patch looks good. The only question I have is why you
didn't want the pgport rename/unlink calls?
Because I wanted the standard platform behaviour of both. For backend
storage subsystem purposes, it's certainly necessary to emulate *ix
behaviour of deleting a file in use, but for generic file access IMHO
the generic behaviour should be exposed.
I'm going to repeat my firm opposition to this patch. Under the
innocuous-sounding banner of "server instrumentation", you are once
again trying to put in generic file access capabilities that will allow
remote Postgres superusers full access to the server filesystem.
[well stated security objections snipped]
(Since we're visiting this again)
It also just strikes me as just the wrong way to go about solving the
apparent problem. If we want to make remote configuration or other
operations possible, then instead of granting access to server resident
files we should invent and implement an API that provides superusers the
appropriate operations. For one thing, this would mean that if we ever
decided to replace the current flat file system we use with something
else we need not break clients that use the API. Just granting file
access even if restricted to the data dir strikes me as a kludge.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
