Re: [HACKERS] Installation procedure wishes
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] Installation procedure wishes |
Дата | |
Msg-id | m10ukUO-0003kLC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Installation procedure wishes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Installation procedure wishes
|
Список | pgsql-hackers |
> > 3. Next step is adding plpgsql into database template1 (or patching creatdb > > script) to add plpgsql every time as I create new db > > That's a one-command thing now, so I'm not seeing why it's harder to issue > the command than type a configure option ... Initially I thought it would be nice to offer those procedural languages that can be TRUSTED ones to regular users by default. So I first added the appropriate commands to initdb. Some complained and I moved them out again and added the new commands (createlang and destroylang) instead. And I agree - I was wrong. It's bad practice to install things by default that some don't need. A database system has some defined priorities: 1. Reliability 2. Reliability 3. Security 4. Reliability 5. Security n. Capabilities, performance and other non-critical items. Adding types/operators/procedural-languages by default to any created database is easy. Add them to the template1 database. If you forgot it during an upgrade or restore, be sure some user will tell you soon. But if you have choosen the conservative way of beeing a site admin, noone will ever tell you if you forgot to DISABLE a feature after a 50 hour restore marathon. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: