Keith Fiske

And reading back I just noticed you had your premake set to 1. That is most definitely not going to work well trying to handle DST. The default premake is...

I see yeah. I've dealt with DST changes before in another extension and it was not particularly easy ( just don't do anything - https://github.com/keithf4/mimeo/blob/master/doc/mimeo.md). I think it would be...

Be very careful using `timestamp` vs `timestamptz`. That almost never has the use-cases that people intend for it. It literally stores the time exactly as given with no context to...

You found the `retention_schema` option which is the closest thing I currently have supporting that right now. `partition_data_*` is primarily for moving data when initially setting up a partition set...

As of PG12+, it's actually using partition pruning which is more performant than plain constraint exclusion. I'm not sure the extent of the overhead for partition pruning, I believe there...

Apologies for the delay in response. Hadn't looked back at pg_partman issues for a while and catching up now. The constraint optimization is called in the `create_partition_*()` functions. https://github.com/pgpartman/pg_partman/blob/master/sql/functions/create_partition_id.sql#L327 https://github.com/pgpartman/pg_partman/blob/master/sql/functions/create_partition_time.sql#L432...

Thinking more on this, though, I'm not sure how you'd determine that the cluster may or may not need to run anymore. Ideally it would only be a one-off operation...

Will review cluster handling again as part of 5.0 since I can then ignore any trigger-based partitioning issues around that. Marking this issue for that milestone.

Odd that it didn't throw an error. Will see if I can fix that. Thanks!

For the next version of pg_partman, it will throw an error if the data type is numeric. I'd like to test things more extensively to see if there would be...