datetime_string format isn't followed by all functions

[Adipa Wijayathilaka]

It doesn't look like all the functions seem to follow the config set via datetime_string range partition types?

Steps to reproduce

Create a partitioned table, configure partman for it + customize the datetime_string format

create table public.partman_test
(
    date timestamp with time zone NOT NULL
) PARTITION BY RANGE (date);

SELECT partman.create_parent(
   p_parent_table => 'public.partman_test',
   p_control => 'date',
   p_type => 'range',
   p_interval=> '1 hours',
   p_premake => 24
);

UPDATE partman.part_config SET
    datetime_string = 'YYYY_MM_DD_HHMI'
WHERE parent_table = 'public.partman_test';

This out of the box unfortunately doesn't use the updated datetime_string format, since create_parent creates an initial set of partitions before the config is updated.

SELECT partman.show_partitions (
   'public.partman_test'
);

show_partitions
(public,partman_test_p20240529_130000)
(public,partman_test_p20240529_140000)

Creating partitions with create_partition_time seems to properly follow the updated datetime_string format

SELECT partman.create_partition_time (
       'public.partman_test',
       p_partition_times  => ARRAY['2024-05-28']::timestamptz[]
);

SELECT partman.show_partitions (
   'public.partman_test'
);

show_partitions
(public,partman_test_p2024_05_28_1200)
(public,partman_test_p20240529_130000)

I then wondered about maybe dropping the partitions and recreating with partition_gap_fill.
However partition_gap_fill doesn't seem to follow the datetime_string format

SELECT partman.partition_gap_fill(
   'public.partman_test'
);

SELECT partman.show_partitions (
   'public.partman_test'
);

(table truncated for clarity)

show_partitions
(public,partman_test_p2024_05_28_1200)
(public,partman_test_p2024_05_28_0100)
(public,partman_test_p2024_05_29_1000)
(public,partman_test_p2024_05_29_1100)
(public,partman_test_p20240529_130000)
(public,partman_test_p20240529_140000)
(public,partman_test_p20240529_150000)

======

I am wondering if this isn't really a bug? Is the intent that if you customize datetime_string to drop partitions created by create_parent to create from scratch altogether?

EDIT: 😮‍💨 Sorry! Forgot to check out the discussions section, this is already a known thing it seems: #380 (comment)

[Keith Fiske]

So it does look like the gap fill is honoring your new datetime_string if I'm reading it right. It filled the gap between (public,partman_test_p2024_05_28_1200) and (public,partman_test_p20240529_130000) with hourly tables that are using your new string value.

You're correct that you cannot create the initial child tables with a new datetime_string value. But there's not that many tables to rename if it's a brand new partition set.

[Adipa Wijayathilaka]

Agreed, the number of partitions is very manageable since at least from what I could tell it is only create_parent that doesn't honor the value (well, more because the config has to be set after the call)

I think to stick to the happy path as part of a v4 to v5 migration should definitely try to stick to the default datetime string convention.

If I read the thread in discussions right, you are open to customizingdatetime_string via the create_parent caller as an optional argument?

This thread can be closed, thanks for the quick response!

[Keith Fiske]

No, I'm not likely to allow that as a parameter to create_parent(). I'd prefer to only officially support the datetime_strings that are built in. The fact that users can change it with some additional work on their part is just a happy coincidence.