On Mon, Dec 13, 2010 at 9:41 PM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> Hmm, I've expected that the EXTENSION patch would use the SQL functions
> like as SPI_exec("SELECT pg_execute_sql(pg_read_file($1))", ...), but
> it actually uses internal functions and nested DirectFunctionCalls.
> So, the most important part of this patch is allowing to read any
> files in the server file system. The current pg_read_file() allows
> to read only files under $PGDATA and pg_log.
As Tom says, this is clearly not going to fly on security grounds.
> However, the interface of current pg_read_file() is mis-designed
> to read files in multi-byte encoding because
> 1. The encoding must be same with the server encoding.
> 2. Users need to specify correct offset in the file
> not to split multi-byte characters.
> So, it'd be better to improve pg_read_file() aside from EXTENSION anyway.
> I think pg_read_whole_binary_file() is one of the solutions for the issue.
I don't have any problem with a separate patch to try to improve some
of these issues, but this is supposedly part of the extensions work,
yet (1) most of what's here has little to do with extensions and (2)
extensions don't need this stuff exposed at the SQL level anyway. I'm
inclined to mark this patch as Returned with Feedback. The portions
of this patch that are trying to fix multi-byte encoding issues can be
submitted as a separate patch that just does that. Whatever material
here is relevant to extensions can either be resubmitted with all of
these other things taken out, or just get absorbed into the main
extensions patch if (as I suspect) there isn't enough there to warrant
a separate patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company