Robert Haas <robertmhaas@gmail.com> writes:
> So there are really four changes in here, right?
> 1. Relax pg_read_file() to be able to read any files.
> 2. pg_read_binary_file()
> 3. pg_execute_sql_string()/file()
> 4. ability to read a file in a given encoding (rather than the client encoding)
> I think I agree that #1 doesn't open any security hole that doesn't
> exist already.
That function would never have been accepted into core at all without a
locked-down range of how much of the filesystem it would let you get at.
There is nothing whatsoever in the extensions proposal that justifies
dropping that restriction. If you want to put it up as a separately
proposed, separately justified patch, go ahead ... but I'll vote against
it even then. (I will also point out that on SELinux-based systems,
relaxing the restriction would be completely useless anyway.)
> I think #2 might be a nice thing to have, but I'm not sure what it has
> to do with extensions.
Agreed. There might be some use for #4 in connection with extensions,
but I don't see that #2 is related.
BTW, it appears to me that pg_read_file expects server encoding not
client encoding. Minor detail only, but let's be clear what it is
we're talking about.
regards, tom lane