Re: Old tsearch functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Howard News <howardnews(at)selestial(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Old tsearch functions
Date: 2019-01-31 14:58:11
Message-ID: 2708.1548946691@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Howard News <howardnews(at)selestial(dot)com> writes:
> On 30/01/2019 18:08, Tom Lane wrote:
>> Note that if you had those functions laying around ever since 8.3,
>> they're probably just "loose" and not wrapped into an extension at all.

> unfortunately running
> create extension tsearch2 from unpackaged;
> caused the following error:
> ERROR: operator family "gist_tsvector_ops" does not exist for access
> method "gist"

That's odd, the tsearch2 extension has certainly been stagnant since
8.3. I wonder if the set of tsearch2 objects you have is even older
than that.

> So I think I will have to create a script to delete the functions etc
> individually unless someone has another idea.

I'd try trimming down the tsearch2--unpackaged--1.0.sql script until
it succeeds. (Don't assume that you've got the exact same set of
objects in every DB, either ...)

> For the tables that contain tsvector columns, is it OK to just run the
> following, or will i need to rebuild the associated index?
> ALTER TABLE public.mytable
>     ALTER COLUMN fts TYPE tsvector ;

The ALTER COLUMN will take care of rebuilding indexes, but just for
certainty I'd suggest spelling that "TYPE pg_catalog.tsvector".

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Howard News 2019-01-31 15:47:18 Re: Old tsearch functions
Previous Message Radoslav Nedyalkov 2019-01-31 14:29:54 Re: Initial load from standby in logical replication.