Re: Proposal: functions get_text() or get_url()
От | Tom Lane |
---|---|
Тема | Re: Proposal: functions get_text() or get_url() |
Дата | |
Msg-id | 2865.1242688235@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: functions get_text() or get_url() (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Proposal: functions get_text() or get_url()
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, May 18, 2009 at 4:03 PM, Stefan Keller <sfkeller@gmail.com> wrote: >> I'd expect functions like get_text() or get_url() in order to do the >> following: >> INSERT INTO collection(id, path, content) VALUES(1, '/tmp/mytext, >> get_text('/tmp/mytext)); Apparently you've not found pg_read_file() ? >> AFAIK there was a get_url in libcurl but I neither find it any more. But >> anyway: This should be part of the core... :-> > Putting this into core would have security implications. The file or > URL would be downloaded by the PostgreSQL server process, not the > client process - therefore I think it would have to be super-user > only, which would make it much less useful. Yes. I very strongly doubt that we'd accept a url-fetching function at all. Aside from the security issues, it would necessarily pull in a boatload of dependencies that we'd prefer not to have. Of course, you can write such a thing trivially in plperlu or several other untrusted PLs, and include any security restrictions you see fit while you're at it. I'm not seeing how a built-in function that would have to impose one-size-fits-all security requirements would be an improvement. regards, tom lane
В списке pgsql-hackers по дате отправления: