Tom Lane wrote:
>
> Fernando Nasser <fnasser@redhat.com> 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: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9