Re: pg_pltemplate entries for external PLs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_pltemplate entries for external PLs
Date
Msg-id 26889.1230739285@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_pltemplate entries for external PLs  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: pg_pltemplate entries for external PLs  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: version() output vs. 32/64 bits
Next
From: Tom Lane
Date:
Subject: Re: TODO items for window functions