Re: pg_execute_from_file, patch v10
От | Itagaki Takahiro |
---|---|
Тема | Re: pg_execute_from_file, patch v10 |
Дата | |
Msg-id | AANLkTi=ORNKZidAfJKsh1pGwBJi49EcsBReEA9E60YMj@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_execute_from_file, patch v10 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_execute_from_file, patch v10
Re: pg_execute_from_file, patch v10 |
Список | pgsql-hackers |
On Tue, Dec 14, 2010 at 10:53, Robert Haas <robertmhaas@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 specifycorrect 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
В списке pgsql-hackers по дате отправления: