Partitioned tables cannot have BEFORE / FOR EACH ROW triggers

[captaincoordinates]

Executing migrations/pgstac.0.4.3.sql on PostgreSQL 12.8 fails with the following

"items" is a partitioned table
Partitioned tables cannot have BEFORE / FOR EACH ROW triggers

Issue #63 reported the same error, and the issue was later closed by the same user reporting "Forgot to install pg_partman.", indicating that installing pg_partman solved the problem. However PR #66 removed pg_partman from the list of required extensions. My testing suggests pg_partman does not make a difference.

pgstac.0.3.4.sql fails in the same way on PostgreSQL 12.8.
pgstac.0.4.3.sql succeeds in PostgreSQL 13.4 with no further changes besides version number.

To reproduce: https://github.com/captaincoordinates/pgstac-pg12-test/

1. Does pgstac still support PostgreSQL 12.x?
2. Is pg_partman required for 12.x?

Any feedback much appreciated 🙏

[bitner]

pg_partman is NOT required anymore. PGStac includes its own functionality for managing partitions.

Yes, it appears a change was made in partition handling that requires PostgreSQL 13+. I will update the documentation to indicate that.

Note that the current hard-coded 1 week duration layout of partitions will be changing at version 0.5 (see issue #83)

[captaincoordinates]

@bitner thanks for the feedback. Two follow-up questions if you have a moment:

1. Is there a past version, prior to this change, that should work with pg 12? I wasn't able to find one in my testing but if you have an opinion I could look more closely.
2. I'm not clear from your comment - are you suggesting that Support for arbitrary partitioning #83 might address a compatibility issue in pg 12, or is this unrelated to problems with 12?

[bitner]

I was only mentioning that other issue to reference there are going to be major changes to partitioning at version 0.5.0.

Given that I unfortunately did not even notice that PG 12 was not compatible, I am not sure what version (if any - I could have just made a wrong assumption) of PGStac would work with PG12. I'm certainly open to PRs that would implement multi-pg-version testing, but that is not on my radar right now.

PG13+ has definitely always been the suggested version as there are a number of performance benefits that were made available in PG13 that have a strong impact on PGStac.

There have also been large enough changes in PGStac (bugs, features, performance) that I would not recommend using an older version.

As far as I know, every major PostgreSQL hosting platform now supports PG13. Is there any reason why you need to stick with PG12? If so, I could likely make some changes as I rework the partitioning logic for v0.5 that would enable you to use PG12 - with the exception that you would need to manually manage partition creation.

[captaincoordinates]

The only reason we need 12 is because AWS RDS Proxy currently only supports up to 12 in PostgreSQL and Aurora-PostgreSQL, even though RDS itself supports 13. Amazon is frustratingly slow in incorporating new versions but RDS Proxy provides real benefits in our stack.

Support for 12 would be nice but I don't think our needs warrant the kind of effort that might be required to work through this. I mainly just wanted to confirm that I had correctly interpreted the situation before committing time to other options, like PgBouncer in place of RDS Proxy.

I appreciate your input, and agree it's appropriate to close this issue with a documentation change.

[drnextgis]

Amazon RDS Proxy now supports PostgreSQL major version 13