Remove support for pre-9.3

[decibel]

I'd like to officially remove support for pre-9.3 versions of Postgres, due to issues in #128. 9.2 went EOL 6 months ago.

https://travis-ci.org/decibel/pgtap/builds/358206497 shows the failures that #128 is getting (I believe #161 explains the version 10 failure). It might be possible to fix the upgrade tests for 9.1 and 9.2, as it appears that the issue is simply some minor changes to output formatting, but I'm not sure it's worth it. Another option would be to simply disable upgrade tests in 9.1 and 9.2 (I'll actually go commit that right now).

9.0 and 8.4 flat-out fail with the changes I've made to Makefile. Possibly fixable, but I definitely don't think it's worth the effort for branches that are 2.5 and 3.5 years past their expiration dates.

[rodo]

sounds good 👍

[theory]

I suggest posting to the mail list to take the temperature of the community. I've had pretty strong pushback on dropping old versions in the past, but I admit that was years ago.

[theory]

If we drop support for 9.0 and earlier, I'd like to suggest we also commit this change:

diff --git a/sql/pgtap--0.98.0--0.99.0.sql b/sql/pgtap--0.98.0--0.99.0.sql
index 36ad40a..f7e28cf 100644
--- a/sql/pgtap--0.98.0--0.99.0.sql
+++ b/sql/pgtap--0.98.0--0.99.0.sql
@@ -12,7 +12,7 @@ RETURNS text AS $$
     SELECT array_to_string(ARRAY(
         SELECT quote_ident($1[i])
           FROM generate_series(1, array_upper($1, 1)) s(i)
-         ORDER BY $1[i]
+         ORDER BY $1[i] COLLATE "C"
     ), $2);
 $$ LANGUAGE SQL immutable;
 
@@ -21,7 +21,7 @@ RETURNS text AS $$
     SELECT array_to_string(ARRAY(
         SELECT $1[i]
           FROM generate_series(1, array_upper($1, 1)) s(i)
-         ORDER BY $1[i]
+         ORDER BY $1[i] COLLATE "C"
     ), $2);
 $$ LANGUAGE SQL immutable;
 
diff --git a/sql/pgtap.sql.in b/sql/pgtap.sql.in
index 3529438..710694e 100644
--- a/sql/pgtap.sql.in
+++ b/sql/pgtap.sql.in
@@ -10026,7 +10026,7 @@ RETURNS text AS $$
     SELECT array_to_string(ARRAY(
         SELECT quote_ident($1[i])
           FROM generate_series(1, array_upper($1, 1)) s(i)
-         ORDER BY $1[i]
+         ORDER BY $1[i]::TEXT COLLATE "C"
     ), $2);
 $$ LANGUAGE SQL immutable;
 
@@ -10035,6 +10035,6 @@ RETURNS text AS $$
     SELECT array_to_string(ARRAY(
         SELECT $1[i]
           FROM generate_series(1, array_upper($1, 1)) s(i)
-         ORDER BY $1[i]
+         ORDER BY $1[i]::TEXT COLLATE "C"
     ), $2);
 $$ LANGUAGE SQL immutable;
\ No newline at end of file

[sgrinko]

Hello,
From which version do you plan to implement this feature?
(I am interested in the implementation of task #168)

[decibel]

So.... I've got a branch where I've tested 8.1 through 11. 9.0 and older don't work because the travis script can't find appropriate packages. Also, we're unable to test versions older than 9.4 due to issue #212; that build has a work-around that disables extension testing if the extensions don't exist.

Based on these results, my thought is to do the following:

• Allow telling the Makefile to explode if unable to test extensions and use that by default in Travis. That way we'll know if that testing suddenly stops working, but will be able to un-break Travis easily.
• Do a final release with support for 9.1+, since that appears to work currently.
• Finally deprecate at least < 9.4 in the next release since community deprecated 9.3 a year ago.

I think we should also adopt a formal policy of dropping support for deprecated versions, although in order to do that I think we'll need to be able to support patch releases (issue #210).

[theory]

Why do you think we'd need to support patch releases in the version returned from pgtap_version()?

[jnasbyupgrade]

Coming back to this after looking at some improvements to function tests...

I don't remember why I was thinking we needed #210 as part of this.

The reason I'm coming back to this now is there's a bunch of attributes that have been added to functions (ie, parallel, leakproof, support, SET, cost/rows), and trying to add testing support for all of that while staying compatible back to ancient history would be a pain. So I think there's two questions at this point:

1. Can we drop support for a bunch of old versions in the next release?
2. Should we have a formal policy of how far back we support? (I think it's OK if we maintain support on really old stuff until it becomes a pain, but it'd be great if we didn't have to have a discussion every time it comes to removing support...)

[theory]

1. I think so. We can keep a branch for the older version and fix anything serious that might cone up in a back patch.
2. Agreed, and WFM. Maybe formally commit to supporting official Postgres-supported versions plus one?

Nice to have you back, @jnasbyupgrade.

[jnasbyupgrade]

I'm a bit reluctant to commit to n+1 versions. I'm worried that if the community added something that was a real pain to be backwards compatible with we'd want to be able to ditch that ASAP. I don't feel any particular need to exceed what the community does in terms of support either.

Note that I'm not suggesting we MUST remove compatibility as soon as a version hits EOL... I think we can simply wait until it would require extra work to keep something working.

Towards that vein, I don't plan on immediately dropping anything. Rather I'll do that as part of other PRs as it makes sense.

[theory]

WFM.