Thread: pg_pltemplate entries for external PLs
Hi, Are we going to add pg_pltemplate entries for external PLs for 8.4? I mean new rows for PL/pgPSM, PL/LOLCODE, PL/php, that sort of stuff. I think we should. In fact AFAIR we said we were going to, back when this catalog was invented. This seems like a good time. Thoughts? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Are we going to add pg_pltemplate entries for external PLs for 8.4?
> I mean new rows for PL/pgPSM, PL/LOLCODE, PL/php, that sort of stuff.
> I think we should. In fact AFAIR we said we were going to, back when
> this catalog was invented.
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; though there is a new issue
since 8.1 days, which is whether tmpldbacreate ought to be on or not
in such entries.
regards, tom lane
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. Ultimately, as we add more loadable facilities (languages, plugins/modules, foreign-data wrappers), we will need a better upgrade mechanism anyway than maintaining our own override list of everything in the world. So let's just leave this mechanism restricted to the built-in languages for now.
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
Tom Lane wrote: >> 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. I have argued this problem to death before. Highlights: http://archives.postgresql.org/pgsql-hackers/2005-09/msg00353.php http://archives.postgresql.org/pgsql-hackers/2005-09/msg00370.php http://archives.postgresql.org/pgsql-hackers/2005-09/msg00379.php Few people followed me, but then again, I think few people have had the amount of interaction with PL development and packaging across many PLs, PG releases, and operating system releases. The consequences from implementing this would be severe and real, versus what I can only understand as a small convenience gain (typing CREATE LANGUAGE versus running some small .sql script). From a packager's perspective, this development would be horrible. You'd either have to tie all postgresql packages and PL packages together by exact version, thus severely obstructing progress and modularity. PL packages might, and usually do, have other dependencies, and pretty soon you will have a huge fixed-version dependency chain between all programming languages implementations in the distribution. The alternative would be to request pltemplate updates as PLs are released, which would require initdb at random times during a stable release life. And no, I don't in general believe what the authors say. For example, you can compile PL/Java in various ways, and the properties depend on which you you compile it. And PL/Ruby at one point had somewhat pecular installation path requirements that would defeat templating. And I don't believe that the authors were completely aware of those issues. They normally only surface in downstream packaging. It is one thing when you provide defaults. Or when the paths are weird and you can patch them. But here you have defaults that you can't override and that are stored in a different package. It's completely silly. Please don't do it.