>
> 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.
>
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.
Maybe we can have second API, which isn't usable for loading of dump,
but can be used for API compatibility. This API can be more cleaner
and can be stored in contrib.
else there are two points
* load or trasformation dump
* application's modification for new API
>
> 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.
>
Migration is one true way. But I know lot of admins who are unable do it :(
Pavel
> 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.
>