Can't find changelog/release notes with enough details for change in create_parent.

[vbhosle]

With docker image postgres:13.10 + postgresql-13-partman installed on top of it.
Following syntax worked.

SELECT partman.create_parent(p_parent_table:= 'public.invoice', p_control:= 'purchase_time', p_type:= 'native', p_interval:= 'monthly', p_start_partition := to_char(date_trunc('month',CURRENT_TIMESTAMP), 'YYYY-MM-DD'), p_premake:= 2);

But with postgres:14.1 + postgresql-14-partman
Above syntax throws error at two places.

1. p_type 'native' is not supported, you have to use 'range'
2. p_interval 'monthly' is not supported, you have to use this syntax https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT

Supported syntax there is
SELECT partman.create_parent(p_parent_table:= 'public.invoice', p_control:= 'purchase_time', p_type:= 'range', p_interval:= '1 months', p_start_partition := to_char(date_trunc('month',CURRENT_TIMESTAMP), 'YYYY-MM-DD') , p_premake:= 12);

I have multiple production/non-production zones. Some use postgres 13.10 some use 14.
How do I write a script that will work for both? How do I find out which version of partman is being used using a query? or which version of above statement is supported

I couldn't find elaborate changelog that highlight these differences. Please help me find it. It is required to get full clarity about changes.

[keithf4]

The general changelog for 5.0 is here

https://github.com/pgpartman/pg_partman/blob/master/CHANGELOG.md

I do have a more extended 5.0 upgrade guide here that tries to cover the bigger issues people may face during a migration

https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman_5.0.1_upgrade.md

As far as the new syntax for create_parent() function and any other function, the doc reference should hopefully help.

https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md

I'd written in the changelog that the syntax for many functions had changed quite a bit. Trying to document every single change individually would have been quite a lot of work which is why I just made the general statement to please review the docs for all the function calls you may be making. I've hopefully made the function documentation easier to read and also made things more consistent across the extension overall so hopefully it's better for you going forward.

You can get the version of any extension internally from the pg_extension system catalog.

SELECT extversion FROM pg_extension WHERE extname = 'pg_partman';
 extversion 
------------
 5.0.1

pg_partman's versions are always 3-dot numeric, so you should be able to parse it for comparisons that way.

SELECT split_part(extversion, '.', 1)::int AS major_version
    , split_part(extversion, '.', 2)::int AS minor_version
    , split_part(extversion, '.', 3)::int AS patch_version 
FROM pg_catalog.pg_extension 
WHERE extname = 'pg_partman';

 major_version | minor_version | patch_version 
---------------+---------------+---------------
             5 |             0 |             1

Just note that not all extensions follow a numeric system, so if you need to do that sort of comparison with multiple extensions, you'll have to deal with each extension's versioning system (it may not even be number based).

[vbhosle]

Thanks @keithf4, it helped to write a stored proc that will handle version differences for out current requirements.