On Tue, Dec 14, 2010 at 18:01, Dimitri Fontaine <dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
