Re: Proposal: functions get_text() or get_url()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stefan Keller <sfkeller(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: functions get_text() or get_url()
Date: 2009-05-18 23:10:35
Message-ID: 2865.1242688235@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 18, 2009 at 4:03 PM, Stefan Keller <sfkeller(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message decibel 2009-05-19 03:03:11 Re: Show method of index
Previous Message Robert Haas 2009-05-18 20:50:07 Re: Proposal: functions get_text() or get_url()