"Pavel Stehule" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster