Thread: pg_database datistemplate

Hello,

In the docs it is mentioned for datistemplate that

"If true then this database can be used in the "TEMPLATE" clause of
CREATE DATABASE to create the new database as a clone of this one."

However, one can create a database using as template another DB that has
datistemplate set to false.

In this situation, what is the point of having datistemplate?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Now I have my system running, not a byte was off the shelf;
It rarely breaks and when it does I fix the code myself.
It's stable, clean and elegant, and lightning fast as well,
And it doesn't cost a nickel, so Bill Gates can go to hell."

>In the docs it is mentioned for datistemplate that
>
>"If true then this database can be used in the "TEMPLATE" clause of
>CREATE DATABASE to create the new database as a clone of this one."
>
>However, one can create a database using as template another DB that has
>datistemplate set to false.
>
>In this situation, what is the point of having datistemplate?

If datistemplate is true, any user with CREATEDB privileges can clone the 
database.
If datistemplate is false, only a cluster superuser can clone the database.

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> In the docs it is mentioned for datistemplate that
> "If true then this database can be used in the "TEMPLATE" clause of
> CREATE DATABASE to create the new database as a clone of this one."

Right.

> However, one can create a database using as template another DB that has
> datistemplate set to false.

Only if one is owner of the source database (or superuser).

> In this situation, what is the point of having datistemplate?

Effectively, it's a "grant right to copy" flag.

Now that we have per-database ACLs, we should probably replace
datistemplate with an access right; instead of setting it you'd
do something like GRANT COPY ON DATABASE foo TO PUBLIC.

(We'd also talked about replacing datallowconn with an access right,
although that is more likely to break existing apps, since a fair
number of them look at datallowconn.)

Too late for 7.3 though ...
        regards, tom lane

On Thu, Oct 24, 2002 at 04:39:51PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > In the docs it is mentioned for datistemplate that
> 
> > However, one can create a database using as template another DB that has
> > datistemplate set to false.
> 
> Only if one is owner of the source database (or superuser).

Oh, I see.  This is a doc bug, isn't it?  I will submit a patch for
this.  I think I've seen other oversights; will try to keep note of
them.

> Now that we have per-database ACLs, we should probably replace
> datistemplate with an access right; instead of setting it you'd
> do something like GRANT COPY ON DATABASE foo TO PUBLIC.

Sounds good.  Altering system catalogs directly is "a bad thing", IMHO.

> (We'd also talked about replacing datallowconn with an access right,
> although that is more likely to break existing apps, since a fair
> number of them look at datallowconn.)

Maybe keep both for a release, and deprecate datallowconn?

Anyway, there are a number of minor things that could use ALTER <foo>
support.  I'll try to make a note of those too, and fix them if I can.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La conclusion que podemos sacar de esos estudios es que
no podemos sacar ninguna conclusion de ellos" (Tanenbaum)

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Thu, Oct 24, 2002 at 04:39:51PM -0400, Tom Lane wrote:
>> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
>>> However, one can create a database using as template another DB that has
>>> datistemplate set to false.
>> 
>> Only if one is owner of the source database (or superuser).

> Oh, I see.  This is a doc bug, isn't it?

It's mentioned somewhere, but perhaps not where you were looking ...
        regards, tom lane