Re: pg_execute_from_file, patch v10

On Tue, Dec 14, 2010 at 11:48 AM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)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