Consider ending support for PostgreSQL <= 10

[andyatkinson]

Hi @ankane

From https://www.postgresql.org/support/versioning/, PostgreSQL version 10 is listed as no longer supported. As of this writing (February 2023), the current released version in Fall of 2022 of PostgreSQL is version 15.

AWS RDS also may forcibly upgrade customers running 10 or earlier that haven't upgraded as well. AWS has encouraged customers to get upgrades done to newer versions than 10 in this page: https://aws.amazon.com/blogs/database/upgrade-amazon-aurora-postgresql-and-amazon-rds-for-postgresql-version-10/

In order to simplify the pgslice code, since declarative partitioning was added in PostgreSQL 10, if pgslice sunsetted support for trigger-based partitioning for versions < PostgreSQL 10, then code in pgslice that supports those branches could be removed.

For example, the first conditional branch of this method checks for declarative partitioning, and then supports the older style of partitioning in the else portion of the branch. https://github.com/ankane/pgslice/blob/master/lib/pgslice/cli/add_partitions.rb#L65

If this is something you're open to in a new release of pgslice, I'd be happy to take it on. Although it wouldn't add new functionality, it would simplify the code as a breaking change (possibly a new major version?).

I'm putting pgslice to use at work and spelunking in the code here and there. We only use declarative partitioning. Thanks.

[ankane]

Hey @andyatkinson, I may drop support at some point, but want to keep it around for now for applications that started partitioning with Postgres < 10.

[andyatkinson]

@ankane Couldn't they run the current version though 0.5.0 and then a new major version, e.g. 1.0 could be created (https://github.com/ankane/pgslice/blob/master/lib/pgslice/version.rb#L1)?

I agree though it's likely they'd be frozen in time.

Or Rails style: "we'll only back port critical issues to the 0.5.x family" 😁

It's your call. From my perspective, in 2023 for new users of the gem, there'd be no one using trigger-based partitioning. Crunchy Data also has this post from 2020 on how to migrate to declarative partitioning. https://www.crunchydata.com/blog/how-to-migrate-from-trigger-based-partitioning-to-native-in-postgresql Something like that could help any users migrate and continue to use pgslice using the more modern and supported declarative partitioning.

I'll respect your choice though if you'd rather close this out. You manage a ton of gems and I imagine try and scale your time for support, and weigh decisions like this. Thanks for your work on pgslice, I'm excited to evangelize it to my current team and elsewhere. 😁

[ankane]

That's likely what I'll do if it's ever dropped, but not really in a rush. The migration aspect is interesting, but enabling it would add more complexity than continuing to support trigger-based partitioning.