Tom Lane wrote:
>Andreas Pflug <pgadmin@pse-consulting.de> 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