Tom Lane wrote: > > Fernando Nasser <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Actually that was my initial choice of name, but I changed my mind > >> later. The reason is that the dbadmin should be able to restrict or > >> even delete the public namespace if his usage plans for the database > >> don't allow any shared objects. > > > Can't we prevent creation in there by (un)setting permissions? > > That was what I was referring to by "restrict" ... but ISTM we should > allow dropping the namespace too. Why waste cycles searching it if > you don't want to use it? >
I don't know how the search will be implemented, but it should cost very few instructions (one isnt checks that a list head is zero and another gets the next pointer for the next namespace). And, as we now transform things and keep them as Oids, it will be even cheaper. > > There should be a more practical way of making it empty than having to > > drop > > each object individually (DROP will drop the contents but refuse to > > delete > > the schema itself as it is a pg_ one?). > > I'd expect DROP on a reserved namespace to error out, and thus do > nothing at all. > But we could have: DROP SCHEMA pg_public CONTENTS; or something of a sort (an extension, but a public schema is an extension). And this sintax can come handy for DBAs in general. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
