"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> I created new project on pgfoundry. It's wrapper of integrated
> fulltext and it's binary compatible with TSearch2 API.
> * it works, (I am able load 82 dump without changes)
> * it is ugly :( . I expected, so this wrapper can be more elegant, but
> not. I had to create full dual interface to fulltext.
Surely this shouldn't be creating its own tsvector datatype? Having
both public.tsvector and pg_catalog.tsvector seems like a seriously
bad idea, if only because of confusion. ISTM you should only be
creating new public.foo objects for the functions whose names changed.
Anyway, the picture that's starting to emerge for me is that we
should repurpose contrib/tsearch2 as a repository for scripts
and documentation to help people migrate from previous use of
tsearch2 to use of the new core facilities; and for people who
want to try to *not* migrate, but keep using the old API,
a compatibility module on pgfoundry seems to make sense.
We could alternatively put the migration support into a new
subdirectory named contrib/tsearch_migrate or something like that.
But I'm thinking tsearch2 is a good place because that's where
users of the old tsearch2 are likely to look.
Also, something that's not been addressed at all yet, AFAICS,
is providing a way to migrate an existing tsearch2 *configuration*
(as opposed to data or application code). I'm not sure there can
be any automatic way to do that, but at the very least we need
some documentation about what corresponds to what.
Comments?
regards, tom lane
