Greetings, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > Certain "market leader" database behaves this way as well. I just hope > we won't go as far as them and also create users for schemas (so that > the analogy of user=schema would be complete and working both ways). > Because that's one of the main reasons their users depend on packages so > much, there is no other way to create a namespace without having to deal > with another user which needs to be secured.
I agree that we do *not* want to force role creation on schema creation. > One thing we could do to limit impact of any of this is having > DEFAULT_SCHEMA option for roles which would then be the first one in the > search_path (it could default to the role name), that way making public > schema work again for everybody would be just about tweaking the roles a > bit which can be easily scripted. I don't entirely get what you're suggesting here considering we already have $user, and it is the first in the search_path..? > TBH I would personally prefer if we got rid of search_path as GUC > completely because it makes certain aspects of DDL logical replication > and connection pooling much more complex, but that does not seem to be a > realistic change. No, I don't think we're going to get rid of it. > > opportunity to do so. I do think it would be too weird to create the schema > > in one database only. Creating it on demand might work. What would be the > > procedure, if any, for database owners who want to deny object creation in > > their databases? > > Well, REVOKE CREATE ON DATABASE already exists. That really isn't the same.. In this approach, regular roles are *not* given the CREATE right on the database, the system would just create the schema for them on login automatically if the role attribute says to do so. Thanks! Stephen
signature.asc
Description: PGP signature
