On Tue, Dec 14, 2010 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
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