Dealing with out-of-range values on a PARTITION BY RANGE
Is there a way to get the min/max values I could store within the existing partitions?


And you also ask in a comment:


  Do you know of a way to get the lower and upper bounds of the range by query?


I wouldn't know of any dedicated system catalog information function for this particular purpose. But: 


Range partitioning is based on inheritance internally:


  Individual partitions are linked to the partitioned table with inheritance behind-the-scenes;

Inheritance trees are stored in pg_inherits:


  one entry for each direct child table

Partition bounds are stored in pg_class.relpartbound in internal format (pg_node_tree).
The system catalog information functions pg_get_expr(pg_node_tree, relation_oid) can:


  decompile internal form of an expression



We can build a query from this set of clues. Based on the example for range partitioning in the manual:




SELECT i.inhrelid::regclass
     , partition_bound
     , split_part(partition_bound, '''', 2) AS lower_bound
     , split_part(partition_bound, '''', 4) AS upper_bound
FROM   pg_inherits i
JOIN   pg_class    c ON c.oid = i.inhrelid
     , pg_get_expr(c.relpartbound, i.inhrelid) AS partition_bound
WHERE  inhparent = 'measurement'::regclass;



inhrelid             | partition_bound                                  | lower_bound | upper_bound
:------------------- | :----------------------------------------------- | :---------- | :----------
measurement_y2006m02 | FOR VALUES FROM ('2006-02-01') TO ('2006-03-01') | 2006-02-01  | 2006-03-01 
measurement_y2006m03 | FOR VALUES FROM ('2006-03-01') TO ('2006-04-01') | 2006-03-01  | 2006-04-01 



db&lt;>fiddle here

Limitations:


Extracting lower and upper bound from the string based on single quotes is cheap &amp; dirty. There is probably a cleaner way to extract the value from relpartbound directly.
Only including the first level of inheritance. You have to walk the graph in pg_inherits recursively to cover sub-partitioning.
This builds on several implementation details for declarative partitioning, which is a new feature of Postgres 10. While I do not expect this query to break due to changes in one of the next major versions, there is a chance it might.