From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su> |
Subject: | Re: tsearch2api project |
Date: | 2007-10-17 18:59:09 |
Message-ID: | 9388.1192647549@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>> Surely this shouldn't be creating its own tsvector datatype?
> I would to use only pg_catalog.tsvector. But dump contains CREATE TYPE
> statement, and custom functions which prefere it, because path is:
> public, pg_catalog :(. I didn't find any other solution with full
> compatibility.
I think we are really going to have to tell people to use the removets2
script on their dumps in any case. I can't imagine that it'll be a good
idea to have a bogus tsvector type in the system -- it'll mess things
up going forward. I think probably the sort of solution you should be
after is
1. load the compatibility module;
2. load dump that's been stripped of old tsearch2 stuff;
3. don't have to change anything else.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2007-10-17 19:20:22 | Re: Proposal: PL/pgSQL EXECUTE INTO USING (for 8.4) |
Previous Message | Pavel Stehule | 2007-10-17 18:36:19 | Re: tsearch2api project |