(2010/06/04 18:26), Dimitri Fontaine wrote:
> Tom Lane<tgl@sss.pgh.pa.us> writes:
>> The proposal some time back in this thread was to trust all built-in
>> functions and no others. That's a bit simplistic, no doubt, but it
>> seems to me to largely solve the performance problem and to do so with
>> minimal effort. When and if you get to a solution that's committable
>> with respect to everything else, it might be time to think about
>> more flexible answers to that particular point.
>
> What about trusting all "internal" and "C" language function instead? My
> understanding is that "internal" covers built-in functions, and as you
> need to be a superuser to CREATE a "C" language function, surely you're
> able to accept that by doing so you get to trust it?
>
> How useful would that be?
If we trust all the "C" language functions, it also means DBA can never
install any binary functions having side-effect (e.g, pg_file_write() in
the contrib/adminpack ) without security risks.
If we need an intelligence to identify what functions are trusted and
what ones are untrusted, it will eventually need a hint to mark a certain
function as trusted, won't it?
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
