>>Is the problem with backing up and restoring a database which has tsearch2
>>installed and enabled delt with in Version 7.4 of PostgreSQL?
>
>
> If it's the problem with restoring the tsearch2-related functions, then no,
> and I'm not sure whether it's "fixable" (in the sense that a tsearch2 enabled
> database will do a painless dump/restore).
>
> I've had some success by making sure all tsearch2-related functions
> are in their own schema, which I don't dump or use for restoring;
> before restoring I recreate the schema from a script, then reload
> the other schemas. There's a slight gotcha though which I can't recall
> offhand. I'll try and write it up next time I got through the process.
What I did is I edited my dump and removed all the tsearch stuff. Then
I copied the tsearch2.sql just after the CREATE DATABASE statement.
This ensured that all the dependencies work fine.
Since then, I think PostgreSQL's default dump order has just worked.
The main situation that causes complete breakage is:
CREATE TABLE...
CREATE TYPE...
ALTER TABLE / ADD COLUMN newtype
Basically, any object that you can add dependencies to after it has been
initially created can cause problems. eg. all the CREATE OR REPLACE
commands, etc.
Chris
