Re: pg_database datistemplate - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg_database datistemplate
Date
Msg-id 20021024224846.GA12481@dcc.uchile.cl
Whole thread Raw
In response to Re: pg_database datistemplate  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_database datistemplate  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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)


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_dump and large files - is this a problem?
Next
From: Tom Lane
Date:
Subject: Re: pg_database datistemplate