Re: Including PL/PgSQL by default - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: Including PL/PgSQL by default
Date
Msg-id 3143595BA2575D309F26FC42@ganymede.hub.org
Whole thread Raw
In response to Re: Including PL/PgSQL by default  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- --On Thursday, February 21, 2008 21:33:03 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Josh Berkus <josh@agliodbs.com> writes:
>> On Thursday 21 February 2008 11:36, Tom Lane wrote:
>>> Would it satisfy people if plpgsql were in postgres, but neither
>>> template DB, after initdb?
>
>> No, the real-world use-case we're trying to satisfy is hosted and/or
>> locked-down installations where the developer doesn't have superuser access.
>> So putting it in "postgres" wouldn't help with that.
>
> That statement is content-free, Josh.  Exactly what are you assuming
> this developer *does* have?  For example, if he hasn't got createdb
> privilege, it will hardly matter to him whether any DBs other than
> "postgres" contain plpgsql.  If he does have createdb, it's already
> possible by default for him to create trusted languages including
> plpgsql in his new DB.  So it's still 100% unclear to me who we are
> catering to.

in my case, a client can createdb through a web interface, but can't load 
plpgsql, so we try and remember to add it to the default template when we build 
the server ...

... but, in that case, the interface should be extended to allow loading 
available languages too ...


Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHvjqm4QvfyHIvDvMRAnblAJ9ecKlFQB6ihHuQ1XZ7XBhc0K46nACg3yaO
OIrUlX+KKW3t7sNa6eUZVXU=
=UQ0i
-----END PGP SIGNATURE-----



pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Memory leaks on SRF rescan
Next
From: Tom Lane
Date:
Subject: Re: Memory leaks on SRF rescan