I believe the status quo is to only run the test suite against the “minimum” postgres version, which is currently Postrgres 14.
The question I have is: Does it make sense to update the continuous integration to explicitly run the test suite against Postgres 15 & 16?
It would have caught this one particular error, but I’m not sure it’s worth the added resource consumption. I think if a large percentage of django users are using postgres 15/16, maybe it might make sense. Some sort of poll or data collection might be useful here.
Thank you @john-parton for starting this conversation. I think that if we have code that performs one logic block for postgresql 16 and another logic block for older versions, it would be great if we can have tests run against the two paths.
I’ll wait for further feedback, but my plan would be to grow the scheduled tests (GitHub Action) to include test runs on linux for the older and newer postgresql versions we support. I guess we also need a test run using server side cursors?
+1 for the selifsh reason that If Django tests against more postgres versions it relieves some of the burden on third-party libraries to assess their postgres compatibility.
Personally, I think it’s a bit of wasteful and to catch a single small regression per year in an “experimental” feature (as server side binding is described in our docs)
(rhetorical question) Are we also going to test against 15 different MariaDB versions, dozens of SQLite versions, or hundreds of GIS library combinations, that we currently officially support? I know, I know, according to the last Django survey, PostgreSQL is the most popular, etc.
Thank you everyone. I agree that lowest and highest makes sense. Adjusted my PR accordingly.
The failures reported by John are already showing for PG 16 + server side bindings.
and 
to catch a single small regression per year in an “experimental” feature (as server side binding is described in our docs) 
I know, I know, according to the last Django survey, PostgreSQL is the most popular, etc.