update documentation and changelog

Author: keithf4

CHANGELOG.md

@@ -6,19 +6,19 @@ NEW FEATURES
  - Added new function partition_data_async() to allow smaller batching of data per transaction when moving data out of the default partition. (Github Issue #353)
     - Note this function currently only works with time-based partitioning. ID/integer partitioning is in development.
     - WARNING: While data is in transition between the default and the destination child table using this procedure, it is NOT visible to users of the partition table. See documentation for this function for additional details.
- - Better support filtering out any columns with `p_ignored_columns` while partitioning data using the `partition_data_time()`, `partition_data_id()`, or `partition_data_proc()` utilities. (Github PR#723)
+ - Better support filtering out any columns with `p_ignored_columns` while partitioning data using the `partition_data_time()`, `partition_data_id()`, or `partition_data_proc()` utilities. (Github PR #723)
     - Allows for filtering out GENERATED columns while moving data so that newly generated values will be entered for moved rows.
     - Non-GENERATED columns that are filtered out will either have NULL values or use the default value when rows are moved.
-    - TODO update partition_data_id
- - Added support for uuid-based partition sets to partition_data_time()/partition_data_proc() functions (Github #789)
+ - Added support for uuid-based partition sets to partition_data_time()/partition_data_proc() functions (Github Issue #789)
  - Allow a starting offset to id/integer based partitioning. Added a new parameter to create_parent: p_offset_id. Note that the offset will carry through to all subsequent child tables. Ex: offset of 5 with interval 10 will make lower boundaries 5, 15, 25, etc. (Github Issue #339)
  - Reduce the logging of the dynamic background working runs to be DEBUG1. Changed existing DEBUG1 logging messages in the BGW to DEBUG2.
- - Unlogged tables are still supported in pg_partman as of PostgreSQL 18 and newer, but the parent table can no longer be flagged unlogged. This only works through the template table system in pg_partman.
+ - Unlogged tables are still supported in pg_partman as of PostgreSQL 18 and newer, but the parent table can no longer be flagged unlogged. This only works through the template table system in pg_partman. (Github Issue #774)
 
 BUGFIXES
 --------
- - Allow `partition_data_*()` utilities to properly work when a PK/Unique key is set to GENERATE ALWAYS.
+ - Allow `partition_data_*()` utilities to properly work when a PK/Unique key is set to GENERATE ALWAYS. (Github PR#723)
  - Handle if the given default table already exists when calling `create_parent()`. Helps to better handle migrating an existing partition set to pg_partman.
+ - When disabling the template table in create_parent(), do not error out trying to inherit things from it. (Github #761)
  - Added check to ensure that the default table cannot be manually set as the value of p_source_table in partitioning functions and procedures. This would previously cause an unhandled edge case endless loop since the data moved out of the default was getting moved right back into the default again instead of a new child partition. (Github Issue #353)
  - Always ensure transaction is committed at proper time when using reapply_constraints_proc(). (Github PR#780)
  - Added plpgsql as a required dependency in the extension control file. (Github PR# 808)
@@ -27,6 +27,7 @@ DOCUMENTATION
 -------------
  - Updated documentation for the time decoder function to note that it must take a TEXT value as its parameter at this time.
 
+
 5.2.4
 =====
 BUG FIXES

doc/pg_partman.md

@@ -114,7 +114,14 @@ See the `create_sub_parent()` & `run_maintenance()` functions below for more inf
 
 ### Retention
 
-If you don't need to keep data in older partitions, a retention system is available to automatically drop unneeded child partitions. By default, they are only uninherited/detached not actually dropped, but that can be configured if desired. There is also a method available to dump the tables out if they don't need to be in the database anymore but still need to be kept. To set the retention policy, enter either an interval or integer value into the **retention** column of the **part_config** table. For time-based partitioning, the interval value will set that any partitions containing only data older than that will be dropped (including safely handling cases where the retention interval is not a multiple of the partition size). For id-based partitioning, the integer value will set that any partitions with an id value less than the current maximum id value minus the retention value will be dropped. For example, if the current max id is 100 and the retention value is 30, any partitions with id values less than 70 will be dropped. The current maximum id value at the time the drop function is run is always used.
+If you don't need to keep data in older partitions, a retention system is available to automatically drop unneeded child partitions. By default, they are only uninherited/detached not actually dropped, but that can be configured if desired. There is also a method available to dump the tables out if they don't need to be in the database anymore but still need to be kept.
+
+To set the retention policy, enter either an interval or integer value into the **retention** column of the **part_config** table. For time-based partitioning, the interval value will set that any partitions containing only data older than that will be dropped (including safely handling cases where the retention interval is not a multiple of the partition size). This value must conform to the PostgreSQL interval data type. Note that without any unit qualifier, a raw number value will be converted to seconds. So your value should be something like `1 day`, `1 month`, `2 years`, etc.
+
+https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT
+
+For id-based partitioning, the integer value will set that any partitions with an id value less than the current maximum id value minus the retention value will be dropped. For example, if the current max id is 100 and the retention value is 30, any partitions with id values less than 70 will be dropped. The current maximum id value at the time the drop function is run is always used.
+
 Keep in mind that for subpartition sets, when a parent table has a child dropped, if that child table is in turn partitioned, the drop is a CASCADE and ALL child tables down the entire inheritance tree will be dropped. Also note that a partition set managed by pg_partman must always have at least one child, so retention will never drop the last child table in a set.
 
 ### Constraint Exclusion