Re: tsearch2api .. wrapper for integrated fultext

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Magnus Hagander" <magnus(at)hagander(dot)net>, "Bruce Momjian" <bruce(at)momjian(dot)us>, pgsql-patches(at)postgresql(dot)org, "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>
Subject: Re: tsearch2api .. wrapper for integrated fultext
Date: 2007-11-10 20:20:52
Message-ID: 162867790711101220g25c1a0cbg214250ea7a239bd7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On 10/11/2007, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> > On 10/11/2007, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
>

I forgot. With perl script, dump can be transformed to readable form.

I see forms of port TSearch to integrated full text:

1. clean and prefered .. dump and application are modified
2. dump is modified, application works via some api
3. full wrapper with known issues
4. special smart mode where TSearch2 API functions are dynamicly
converted to fulltext api

like
get function name
if it some from tsearch2 api transform it or forgot it
else create function

but perl script do it well and outside

> 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

It was my original goal. But there is lot of issues.

I found different problem, that have to be solved if wrapper have to
be dump compatible.

there is about five functions with same name, and I have problem with
wrapping, because I create recursive calling. I am not able select
integrated functions. That was reason for use prefix tsa.

>
> 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
>

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2007-11-10 21:53:36 Re: [HACKERS] pg_ctl configurable timeout
Previous Message Tom Lane 2007-11-10 19:09:30 Re: tsearch2api .. wrapper for integrated fultext