Re: Including PL/PgSQL by default

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Including PL/PgSQL by default
Date: 2008-02-22 17:23:41
Message-ID: 47BF051D.6040609@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> For example, since we don't support temp functions, we should probably
>> ban the creation of functions in temp schemas (which I found was possible).
>>
>
> What for? If you don't want someone to use a language, you should
> either revoke his USAGE privilege on that language, or remove it
> from his database altogether.
>

Good point. Actually, this has made me rethink the whole proposal.

Things could get quite sticky if we have initdb put plpgsql in
template1. The language would be owned by the superuser, not the db
owner, and so the db owner would not be able to control usage on it. And
if we withdrew usage on it from public in template1 the db owner
wouldn't even be able to use the language.

So on reflection I'm now inclined to say we should not change what we
are now doing, which is simply to allow the db owner to install and
control access to the language. Perhaps there is a case for removing
public usage from the default ACL for languages, or at least for
installable PLs, but I suspect that would just break huge numbers of
apps, unless we had some sort of grandfather clause.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-02-22 17:24:27 Re: Full-text search default vs specified configuration
Previous Message Robert Lor 2008-02-22 17:13:23 Proposed changes to DTrace probe implementation