An alternative way to fix#168 which is not as invasive as the changes
in #171.
This currently breaks the current behaviour of the program as the tables
specified on command line are not found.
The run part has different output across minor versions, the others not.
Dropped test files identification statement as now the variable part is
in small chunks.
Due to compatibility break by the recent PostgreSQL core code changes
we need to split expected files into each minor releases rather than
each major releases.
Now the mapping between PostgreSQL version and expected file is
complicated as follows.
* version 10
* >= 10.3 : repack_3.out, tablespace_2.out
* < 10.3 : repack_2.out, tablespace.out
* version 9.6
* >= 9.6.8 : repack_4.out, tablespace_2.out
* < 9.6.8 : repack.out, tablespace.out
* version 9.5
* >= 9.5.12 : repack_4.out, tablespace_2.out
* < 9.5.12 : repack.out, tablespace_1.out
* version 9.4
* >= 9.4.17 : repack_5.out, tablespace_2.out
* < 9.4.17 : repack_1.out, tablespace_1.out
* version 9.3
* >= 9.3.22 : repack_6.out, tablespace_3.out
* < 9.3.22 : repack_1.out, tablespace_1.out
* version 9.2 : repack_1.out, tablespace_1.out
* version 9.1 : repack_1.out, tablespace_1.out
Due to change at PostgreSQL 10.3, 9.6.8, 9.5.12, 9.4.17 and 9.3.22,
relation names passed by PostgreSQL function such as
pg_get_indexdef_string() are schema-qualified, which could be cause
of a parse error.
Previously we exited from lock_exclusive() while opening the
transaction that started at beggning if --no-kill-backend option
is specified. This caused that DROP INDEX CONCURRENTLY fails
because it cannot be executed within a user transaction block.
Fixed issue #129.
Commit 5adff6ff0b separated the
data copy from creating table. This is a cause of bug that
pg_repack doesn't actually sort table during reorganization.
This commit fixes this issue by adding ORDER BY clause to Copy
SQL rather than CREATE TABLE SQL.
Reported by acmzero on issue #138.
