Control symbol visibility for functions exported in the pg_repack
shared library, to avoid symbol conflicts with other libraries,
particularly those which may be loaded via shared_preload_libraries
and use conflicting function definitions of our common pgut code,
such as pg_statsinfo.
Verified this fix on my Debian x86_64 machine with PostgreSQL 9.4 and
pg_statsinfo 3.0.2. Would be nice to test this fix on a few other
platforms such as OS X, though I had some difficulty getting
pg_statsinfo to build on OS X. Hopefully closes Issue #43, thanks
to bwtakacy for the report and demonstration of the commited fix in
pg_reorg.
Per Issue #7 from armanddp, it seems the RHEL/CentOS packages
of Postgres are built against libpam, which shows up in
the LIBS reported by pg_config. We don't actually need to
link in libpam for pg_repack, so manually remove it from
our LIBS. This helps a little bit for building on
RHEL/CentOS, though the issue of libpgport.a missing
on that platform still looms.
The -E flag to specify extended regular expressions apparently is
not portable to all platforms, such as CentOS 4.5. Use an uglier
but hopefully more portable basic regular expression in Makefiles.
Not as available as I thought.
Can't use the 0 prefix to make the 3rd number optional as $(()) parses is as
octal, so only use the first 2 numbers.
Also fixed collate test: not available on PG 9.0.
Having the SQL on a different numbering scheme is useful to provide an ungrade
path. But pg_repack has no need of such a path as it can be uninstalled with
no problem, so we are not going to provide update script. Hence it's much
easier to have a single version number for everything.
...not the other way around. This allows DROP EXTENSION ... CASCADE to
remove temporary directories, simplifying the cleanup procedure after an
error, and getting rid of the schema on uninstall.
Provide only CREATE EXTENSION support on PG >= 9.1 and only the sql script on
PG < 9.1.
Also dropped the /echo cruft in the extension script: it is broken on pg 9.1
and 9.1.1, and because the script is not installed on versions that don't
support CREATE EXTENSION it is just not terribly useful.
pg_repack doesn't create any object to depend on, so it is always possible drop
it and install a new version instead of upgrading. Creating a robust upgrade
path from loose objects which can be of any version to a target version is
hopelessly brittle, so I'd suggest the user just to drop a previous pg_repack
version and install the new one.
The behaviour of the script is not really predictable if it is run on the
loose objects of pg_reorg >= 1.1.8. So let's be explicit about what version
we expect as starting point.
I've changed lib/Makefile to support CREATE EXTENSION.
In order to work with previeous PostgreSQL version (i.e. < 9.1),
this implementation installs both pg_reorg--1.0.sql and pg_reorg.sql.
This patch lacks regression testcases for CREATE EXTENSION, which I will commit soon.
there are views or functions depending on columns after dropped ones.
The issue was reported by depesz, and original patch by Denish Patel.
Improved documentation how to build binaries from source.
COPYRIGHT updated.
have a primary key. Some of users want to use not-null unique keys rather than
primary keys because postgres doesn't support REINDEX PRIMARY KEY CONCURRENTLY.
- Support 9.1dev.
- Improve Makefile to use PGXS automatically.
pg_reorg broke catalog definition if the target table had any dropped columns.
Now pg_reorg removes dropped columns and renumbers valid columns.
You can use pg_reorg to shrink column definitions if you have many dropped
columns. (without pg_reorg, dropped columns are filled with zero forever)
