Peter Eisentraut <pete...@gmx.net> writes:
> On Wednesday 31 December 2008 05:50:19 Tom Lane wrote:
>> That was part of the original concept for pg_pltemplate, but IIRC there
>> was push-back from some folks who thought it was a bad idea.  I don't
>> recall what their arguments were exactly;

> Basically, we have no information about what the proper parameters of 
> external 
> languages would be.  (We have some pretty good ideas, but that's not the 
> same.)  Especially if we override the trusted/untrustedness, we could create 
> complete disaster.

Presumably we'd only insert such entries with the concurrence/approval
of the PL's author, so this argument seems pretty darn weak to me.

It's true that we could have another fiasco like the trusted-plpython
one, where something that we thought was trustworthy turns out not to
be; but pg_pltemplate seems unlikely to make such a case much worse than
it is already.  The people who'd be at risk would be the ones who'd
already installed the unsafe language, and where they got the
information that it was safe wouldn't be relevant anymore.

On the other hand, having entries for non-built-in languages in
pg_pltemplate would clearly reduce the chances of DBAs accidentally
creating a language as trusted when it should not be.  I think the odds
are good that this effect would reduce security risks far more than
they'd be increased by the chance of bad entries in pg_pltemplate.

                        regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to