Re: inconsistent owners in newly created databases?

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> Another heavier but more general approach would be to add a boolean to
> pg_database to tell whether the first connection housekeeping was
> performed,

I was envisioning a bool column added to pg_database, and having the set
of operations just hard-coded into the backend. The only input
information the process needs is the DB owner's ID, which it can of
course get from the pg_database row. I doubt that reading a file of SQL
commands is easier --- the file would have to be created somehow, and
since stuff would have to be interpolated into it (owner's ID) you'd end
up with a lot of mechanism that's very different from anything else in
the backend.

One definitional issue that remains to be resolved is "just what is the
public schema anyway?". It is not a built-in object in the same sense
that pg_catalog is. It could be deleted, or even deleted and
re-created. So you certainly have to be prepared for the possibility of
it not being there (strike one for the simple "file of SQL commands").
What I want to know is whether we want to forcibly change owner of any
random schema that happens to be named "public"? Or should we insist on
it having the original OID? Or some other way of identifying it?

In the same vein: we probably need to alter the ACL for public so that
its privileges appear to flow from the object owner and not from the
postgres user. What do we do if the ACL is in a non-default state?

regards, tom lane