> At 14:04 7/11/00 -0500, Jan Wieck wrote:
>> FWIW, what about having another "template0" database, where
>> nobody can add user data. Initially, template0 and template1
>> are identically. CREATE DATABASE get's a new switch (used by
>> the pg_dump output) that tells to create it from the vanilla
>> template0 DB (generalized, so someone can setup a couple of
>> template<n>'s) and all objects inherited from template1
>> (those not in template0) are regularly dumped per database.
I like that a lot. Solves the whole problem at a stroke, and even
adds some extra functionality (alternate templates).
Do we need an actual enforcement mechanism for "don't modify template0"?
I think we could live without that for now. If you're worried about it,
one way would be to not allow connections of any sort to template0...
in fact template0 needn't be a real database at all, just a $PGDATA/base
subdirectory with no pg_database entry. initdb would set it up via
cp -r from template1, and thereafter it'd just sit there.
Philip Warner <pjw@rhyme.com.au> writes:
> The command to create the new database needs to ask for a vanilla database
> somehow, but extending the SQL doesn't seem like a good idea.
Why not? CREATE DATABASE isn't a standard command in the first place,
and it's got a couple of even-less-standard options already. I like
CREATE DATABASE foo WITH TEMPLATE 'template0'
better than a SET command.
> It would also be good to allow some kind of installation-wide default
> template (not necessarily template1/0),
Maybe, but let's not go overboard here. For one thing, where are you
going to keep that default setting? I think a hard-wired default of
template1 is a perfectly good choice.
regards, tom lane