On Tue, Dec 14, 2010 at 1:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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.
I have some angst about opening it up wide, but I'm also having a hard time seeing what problem it creates that you can't already create with COPY FROM or lo_import(). >> 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. OK. -- 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
