On Tue, Dec 14, 2010 at 10:53, Robert Haas <robertmh...@gmail.com> wrote:
> I'm looking at this patch and I'm confused. Why do we need this at
> all? pg_read_binary_file() seems like it might be useful to somebody,
> but I don't see what it has to do with extensions. And the rest of
> this doesn't appear to provide any new functionality. The extension
> mechanism hardly needs SQL-callable functions.
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.
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.
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
