On Tue, Dec 14, 2010 at 18:01, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> In any case, I concur with what I gather Robert is thinking, which is
>> that there is no good reason to be exposing any of this at the SQL level.
>
> That used to be done this way, you know, in versions between 0 and 6 of
> the patch. Starting at version 7, the underlyiong facilities have been
> splitted and exposed, because of the file encoding and server encoding
> issues reported by Itagaki.
I'm confused which part of the patch is the point of the discussion. 1. Relax pg_read_file() to be able to read any
files.2. pg_read_binary_file() 3. pg_execute_sql_string/file()
As I pointed out, 1 is reasonable as long as we restrict the usage
only to superuser. If we think it is a security hole, there are
the same issue in lo_import() and COPY FROM by superuser.
2 is a *fix* for the badly-designed pg_read_file() interface.
It should have returned bytea rather than text.
3 could simplify later EXTENSION patches, but it might not be
a large help because we can just use SPI_exec() instead of them
if we write codes with C. I think the most useful parts of the
patch is reading a whole file with encoding, i.e., 1 and 2.
--
Itagaki Takahiro