Peter Eisentraut <peter_e@gmx.net> writes:
> We are only talking about well-known procedural languages. The issue of
> completely new languages added by the user is addressed by neither
> proposal.
Sure it is: in my proposal, you can add new languages to the template
catalog. (Which admittedly we don't have today. We could have it
tomorrow, though, if an initdb for beta2 is OK.)
>> Also, ISTM your proposal is to cause "CREATE LANGUAGE foo" on an
>> already-existing language to execute "GRANT USAGE ON LANGUAGE foo TO
>> PUBLIC" instead, rather than erroring out. That doesn't seem to pass
>> the least-surprise test at all.
> Clearly, there's going to be some surprise element. The surprise
> element proposed by you is that the command does something completely
> different than specified (which possibly introduces security holes, see
> other mail).
Haven't seen this other mail yet...
> My proposal is that the command does only a subset of
> what it would normally do, which amounts to some sort of implicit "OR
> REPLACE", which people are familiar with.
No, because what the command would normally do in that situation
(the language already exists) is error out. Silently granting rights
is a security risk. What if the DBA already created the language,
adjusted its permissions the way he wants, and then accidentally did
another CREATE LANGUAGE (or more likely, loaded a dump file containing
same)? Now he's got language usage granted to PUBLIC, and he doesn't
even know it. The CREATE OR REPLACE variants that we have don't muck
with the object's permissions, so I don't see them as good precedent.
regards, tom lane
