"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> On 10/11/2007, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * The SQL file doesn't create any of the old types (public.tsvector
>> etc) so it seems still a long ways short of ensuring that an old
>> dump file can be reloaded. Maybe I don't understand exactly how you
>> intend it to interact with the definitions that will be in the dump
>> file.
> with this version of wrapper you cannot load old dumps. It allows
> application compatibility. Dump was readable with older variant which
> is really ugly and that is on pgfoundry.
> Steps with this wrapper:
> a) uninstall tsearch2
> b) dump
> c) install 8.3 and configure fulltext
> d) load
> e) load wrapper
That seems like a non-starter. Existing tsearch2 installations will
have tsvector columns in their tables, so I don't see how they are
going to "uninstall tsearch2" in the existing database. The other
problem is that I think we have to provide a migration path for people
who already have dump files (and, maybe, no longer have the original
installation).
For people who have custom or tar-format dumps, the previously posted
script to strip out the old tsearch2 objects during pg_restore would
help ... but it's useless if you used text dump (notably including
pg_dumpall output).
Another problem that was already noted was that the dump might contain
explicit references to "public.tsvector", or some other schema that you
put the tsearch2 objects in.
The approach that I was hoping to see was
a) dump
b) install 8.3 and configure fulltext
c) load wrapper (into same schema as you used for tsearch2 before)
d) load dump file
Since pg_dump doesn't do CREATE OR REPLACE, step (d) would result in a
lot of error messages, but it wouldn't overwrite any of the function
definitions installed by the wrapper. We could possibly deal with the
schema issue by having the wrapper create public.tsvector as a domain
for pg_catalog.tsvector, etc.
Thoughts?
regards, tom lane