From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Subject: | Re: Including PL/PgSQL by default |
Date: | 2008-02-26 17:35:27 |
Message-ID: | 4945.1204047327@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> On Thursday 21 February 2008 21:33, Tom Lane wrote:
>> So it's still 100% unclear to me who we are catering to.
> There are a lot of people who have a database provider of some sort who
> creates a database for them, giving them ownership of that specific database,
> with pg_hba.conf specifying connection only to that db. They are then free to
> muck about that database, installing anything they want, but they cannot load
> any procedural languages since they only have non-superuser accounts. (This
> does give them access to plsql, but not plpgsql). Sadly a lot of these
> arrangements preclude (for valid reasons or not) the installation of any
> contrib modules or installation of any procedural languages. It is these
> users that 3rd party application developers (ie. mediawiki types) are trying
> to accommodate. They would like to be able to take advantage of plpgsql in
> their applications, but without it being included by default they have to
> exclude it from their application.
That argument *was* valid ... before 8.3. Nowadays non-superuser DB
owners can install trusted PLs in their DBs by themselves. (At least
by default.) So I'm still unconvinced that we need more changes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-02-26 17:43:42 | Re: [COMMITTERS] pgsql: Don't build the win32 support files in the all target, only in |
Previous Message | Greg Smith | 2008-02-26 17:27:13 | Re: pg_dump additional options for performance |