Updated docs

doc/pg_partman.md

@@ -7,10 +7,10 @@ pg_partman is an extension to help make managing time or serial id based table p
 
 For this extension, most of the attributes of the child partitions are all obtained from the original parent. This includes defaults, indexes (primary keys, unique, etc) & constraints. While you would not normally create indexes on the parent of a partition set, doing so makes it much easier to manage in this case. There will be no data in the parent table (if everything is working right), so they will not take up any space or have any impact on system performance. Using the parent table as a control to the details of the child tables gives a more central place to manage things that's a little more natural than a configuration table or using setup functions.
 
-I'm trying to find a way to also inherit the permissions from the parent table in a similar way as above, but until I do that, the following method has been implemented. The "part_grants" table stores csv lists of the grants and roles that should be applied to the parent and all child tables. These grants will be applied to any new partitions as well as re-applying them to the parent and all other child tables whenever a new partition is made. Assume that all grants will be applied in a single command (there is currently a primary key on the parent_table column of the part_grants table). Grants are only applied, never revoked. Here's an example of what to insert there:
+I'm trying to find a way to also inherit the permissions from the parent table in a similar way as above, but until I do that, the following method has been implemented. The "part_grants" table stores csv lists of the grants and roles that should be applied to the parent and all child tables. These grants will be applied to any new partitions as well as re-applying them to the parent and all other child tables whenever a new partition is made. Multiple entries can be made so that different roles can have different grants. Grants are only applied, never revoked. Here's an example of what to insert there:
 
-    INSERT INTO partman.part_config (parent_table, grants, roles) 
-    VALUES ('my_parent_table', 'INSERT,UPDATE,DELETE', 'role1,role2,role3');
+    INSERT INTO partman.part_config (parent_table, grants, roles) VALUES ('my_parent_table', 'INSERT,UPDATE,DELETE', 'role1,role2,role3');
+    INSERT INTO partman.part_config (parent_table, grants, roles) VALUES ('my_parent_table', 'SElECT', 'role4');
 
 If you attempt to insert data into a partition set that contains data for a partition that does not exist, that data will be placed into the set's parent table. This is preferred over automatically creating new partitions to match that data since a mistake that is causing non-partitioned data to be inserted could cause a lot of unwanted child tables to be made. The check_parent() function provides monitoring for any data getting inserted into parents and the create_prev_* set of functions can easily partition that data for you if it is valid data. That is much easier than having to clean up potentially hundreds or thousands of unwanted partitions. And also better than throwing an error and losing the data!