Re: pg_database datistemplate
От | Alvaro Herrera |
---|---|
Тема | Re: pg_database datistemplate |
Дата | |
Msg-id | 20021024224846.GA12481@dcc.uchile.cl обсуждение исходный текст |
Ответ на | Re: pg_database datistemplate (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_database datistemplate
|
Список | 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 по дате отправления: