Re: pg_execute_from_file, patch v10
От | Tom Lane |
---|---|
Тема | Re: pg_execute_from_file, patch v10 |
Дата | |
Msg-id | 14500.1292295060@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_execute_from_file, patch v10 (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Ответы |
Re: pg_execute_from_file, patch v10
|
Список | pgsql-hackers |
Itagaki Takahiro <itagaki.takahiro@gmail.com> writes: > 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. Has anyone thought twice about the security implications of that? Not to mention that in most cases, the very last thing we want is to have to specify an exact full path? I think we'd be better off insisting that the extension files be under sharedir or some such place. In any case, I concur with what I gather Robert is thinking, which is that there is no good reason to be exposing any of this at the SQL level. regards, tom lane
В списке pgsql-hackers по дате отправления: