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

From Andrew Dunstan
Subject Re: Including PL/PgSQL by default
Date
Msg-id 47BDDBF4.6020008@dunslane.net
Whole thread Raw
In response to Re: Including PL/PgSQL by default  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>   
>> Tom Lane wrote:
>>     
>>> Anyway, as I said before, I don't object to installing plpgsql by
>>> default.  What I do object to is installing it in a way that makes it
>>> difficult for the DBA to remove it, as would be the case if it were in
>>> template0 for example.
>>>       
>
>   
>> Perhaps it can be installed in template1 after the copy, if a certain
>> initdb option is passed?
>>     
>
> Yeah, we'd have to rejigger initdb a bit.  The bigger problem is that
> traditionally template0 has been seen as a backup for template1, and it
> wouldn't be (quite) that if the initial contents are different.
>
> Would it satisfy people if plpgsql were in postgres, but neither
> template DB, after initdb?  This would make it available to the sort of
> person who's too lazy to learn about CREATE DATABASE, and one would
> think that if they can handle CREATE DATABASE then CREATE LANGUAGE
> is not beyond their powers.
>
>   

I don't see any point in doing it at all unless it gets into new DBs by 
default. So, no, I don't think that's going to be very helpful.

I don't see a huge problem in loading it to template1 after we copy 
template1 to template0 - anyone who is going to touch template0 at any 
time is likely to have enough postgres-fu to be able to manage.

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: VARATT_EXTERNAL_GET_POINTER is not quite there yet
Next
From: ITAGAKI Takahiro
Date:
Subject: Re: Batch update of indexes on data loading