Re: XversionUpgrade tests broken by postfix operator removal
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org, pgbf@twiska.com
Date: 2020-09-19T14:43:54Z
Lists: pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > On 9/18/20 6:05 PM, Tom Lane wrote: >> Done, you should be able to remove @#@ (NONE, bigint) from the >> kill list. > crake tests pg_upgrade back to 9.2, so I had to mangle those static > repos for non-live branches like this: Oh, hm. Now that you mention that, I see snapper is testing 9.3 and 9.4 upgrades too. It seems like we have these non-kluge fixes available: 1. Backpatch 9ab5ed419 as far as 9.2. It'd be unusual for us to patch out-of-support branches, but it's certainly not without precedent. 2. Give up testing these upgrade scenarios. Don't like this much; even though these branches are out-of-support, they still seem like credible upgrade scenarios in the field. 3. Put back the extra DROP in TestUpgradeXversion.pm. The main complaint about this is we'd then have no test of pg_upgrade'ing prefix operators, at least not in these older branches (there is another such operator in v10 and later). That doesn't seem like a huge deal really, since the same-version pg_upgrade test should cover it pretty well. Still, it's annoying. 4. Undo the elimination of numeric_fac() in HEAD. I find this only sort of not-a-kluge, but it's a reasonable alternative. In the last two cases we might as well revert 9ab5ed419. Personally I think #1 or #3 are the best answers, but I'm having a hard time choosing between them. regards, tom lane
Commits
-
In pg_upgrade cross-version test, handle postfix operators.
- fa744697c791 14.0 landed
-
Use factorial rather than numeric_fac in create_operator.sql.
- cc7b27da7fb8 11.10 landed
- a950fb073426 10.15 landed
- 9ab5ed4194f3 13.0 landed
- 760b8fe766bc 9.5.24 landed
- 1e00333ffa2e 9.6.20 landed
- 1af91dc032cf 12.5 landed
-
Remove support for postfix (right-unary) operators.
- 1ed6b895634c 14.0 cited