Question

I’m one of those that recently decided to migrate from MySQL to PostgreSQL and with it a lot of old habits are being torn apart. However there is functionality from MySQL I would like to preserve in PostgreSQL.

So… topics:

1. User should have ability to create tables under a restricted namespace.
2. Tables of one user should not be visible to other users by default (both data, structure, stored procedures and whatnot).
3. Optionally the user should be given the right to GRANT permissions to other users.
4. Default permission to new users is to have no permission (read nothing, write even less)
5. Maintain compatibility with applications that are not schema aware.

Point 1:

Under MySQL the solution in place was to allow the user to create databases under the criteria ‘username_%’. Under PostgreSQL I thought of having one database per user such that they can create as many schemas as they want. However there is the limitation of not being able to do joins across databases, only across schemas on the same database.

The possibility of having all as PostgreSQL schemas under the same database is not completely discarded. But then it suffers from the next point…

Point 2:

After reading this question I was inclined to think that the only way to make data completely private was to use different databases. Still I can’t seem to figure out how to do it and on the other hand it conflicts with the ability to do the joins mentioned in the previous point.

Point 3:

Is this even possible or do you need the ‘Create roles’ privilege and create a new role for the given table/schema.

Point 4:

Again, is this possible? From what I read it feels like I’m fighting the default ‘public’ behavior, but still I would like to have the users seeing nothing unless an admin gives them access to the information.

Point 5:

Some of the programs I use with MySQL, on which I have no direct control of the actions they perform on the database, are not schema aware. This means they simply ignore the schema layer. For this PostgreSQL provides the ‘public’ schema as default. However this is still a bit awkward in some cases.

It also means that by default I need one independent database per software/tool or else I need to trick the system by setting search_path to some predefined schema on a per user (role) basis.

---

So those are the options/solutions I’ve found so far. I’m fine with having to use the search_path for point 5 and sacrificing joins between tables/schemas in different databases for the sake of privacy (points 1 and 2), but I would still like to know what is the best solution to the above problems and what are the best ways to put them in practice.

With that said, I’m all ears.

PS: Links to information on how to accomplish the mentioned above are also welcome.

Answer 1

The solution we ended up taking is the following:

Point 1:

One database per user. User can create as many tables and schema as he wants. Joins across databases are not possible. The alternative is to retrieve subsets and manage the results on the client, obviously not the most efficient way.

Point 2:

This can be accomplished by defining a specific ownership and permission for a given database and removing the default “public” behavior. With this, only users that belong to allowed groups or are the owner itself can access the content.

Note: PostgreSQL uses multiple level permissions which means that even if the database is owned by someone, tables can be owned by someone else.

Point 3:

Can be done with WITH GRANT OPTION.

Point 4:

There is no automated way to do this. The only way to ensure this is by restricting “public” access to all existing databases.

Point 5:

Using search_path on a per user basis is the only way to do it, using multiple users to access different schema (when needed). There is obviously the issue that a schema unaware application cannot “reach” other schema if no user with appropriate search_path exists.