Re: Including PL/PgSQL by default

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Re: Including PL/PgSQL by default
Дата
Msg-id 3143595BA2575D309F26FC42@ganymede.hub.org
обсуждение исходный текст
Ответ на Re: Including PL/PgSQL by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: Memory leaks on SRF rescan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Memory leaks on SRF rescan