From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Getting rid of pg_pltemplate |
Date: | 2011-08-23 19:09:34 |
Message-ID: | m2bovgosgh.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> We'll add a new boolean parameter to extension control files, called say
> "dba_create" (ideas for better names welcome). If it's missing or set
> to false, there's no change in behavior. When it's true, then
>
> (a) you must be superuser or owner of the current database to create the
> extension;
>
> (b) the commands within the extension's script will be run as though by a
> superuser, even if you aren't one.
That's called sudo on linux. I propose that we stick to such a name.
Do we want a more general SUDO facility in PostgreSQL? It would be, I
guess, about the same thing as SET ROLE postgres; and you would have to
be granted the rights to “upgrade” to being that role. I can see how
relaxing the role membership would help in the case of extensions
though, with the behavior you're describing.
Do you see other places where giving sudoer to a database owner even if
he's not in the postgres (or another superuser) role would be useful?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-08-23 19:12:50 | Re: text search: restricting the number of parsed words in headline generation |
Previous Message | Tom Lane | 2011-08-23 19:05:20 | Re: skip WAL on COPY patch |