In the previous commit skip_const was going ahead the space thus removing the
starting quote. Also fixed (and tested) trailing part after the tablespace
name, e.g. the WHERE clause.
Note: if original namespace is "foo bar", repack_indexdef gives a bad
result. This is weird as apparently skip_ident can deal with spaces in
a quoted identifier. Committing as I'm going home, will deal with that
later.
Bumped version number to enforce extension re-creation as the SQL has
been modified.
Current limitations:
- Check for namespace existence: on error temp objects are left around
- What happens to the indexes?
- Tests needed.
- Should the default be the GUC default_tablespace instead of pg_default?
This is actually an original pg_repack shortcoming, not a regression.
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.
As far as I can tell, the code already supports these index options, so
put in a small installcheck test exercising these index options and call
it good.
Per Issue #12, have the Makefile bail out if the user is trying to build
on an unsupported Postgres version. Also, some further removal of macros
purportedly handling older PG versions which are no longer needed, and
were missed in 370e572.
Fixing the other functions selecting pg_index (as in Josh original patch)
doesn't seem necessary as they are only called with an index oid, and we
should only call them with a valid index as argument.
ALTER TABLE [table_name] ENABLE ALWAYS TRIGGER z_reorg_trigger
so that pg_reorg and the z_reorg_trigger can properly work in "replica" mode,
as when using pg_reorg on a Slony slave.
Bug report and patch by Norman Yamada.
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.
