On Tue, Dec 14, 2010 at 11:48 AM, Itagaki Takahiro <itagaki.takah...@gmail.com> wrote: > 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.
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. We have no similar check for COPY, and both are superuser-only. I also see that this is useful for the extensions work, if that code wants to internally DirectFunctionCall to pg_read_file. I think #2 might be a nice thing to have, but I'm not sure what it has to do with extensions. I don't see why we need #3. I think #4 is useful. I am not clear whether it is needed for the extension stuff or not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
