On Fri, May 21, 2010 at 2:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Joshua Tolley <eggyk...@gmail.com> writes: >> Agreed. As long as a trusted language can do things outside the >> database only by going through a database and calling some function to >> which the user has rights, in an untrusted language, that seems decent >> to me. A user with permissions to launch_missiles() would have a >> function in an untrusted language to do it, but there's no reason an >> untrusted language shouldn't be able to say "SELECT > > s/untrusted/trusted/ here, right?
Er, right. Sorry. > >> launch_missiles()". > > To me, as long as they go back into the database via SPI, anything they > can get to from there is OK. What I meant to highlight upthread is that > we don't want trusted functions being able to access other functions > "directly" without going through SQL. As an example, a PL that has FFI > capability sufficient to allow direct access to heap_insert() would > have to be considered untrusted. That I can definitely agree with. -- Joshua Tolley / eggyknap End Point Corporation -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
