Re: pg_migrator and an 8.3-compatible tsvector data type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_migrator and an 8.3-compatible tsvector data type
Date
Msg-id 2230.1243551141@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_migrator and an 8.3-compatible tsvector data type  (Greg Stark <stark@enterprisedb.com>)
Responses Re: pg_migrator and an 8.3-compatible tsvector data type  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Greg Stark <stark@enterprisedb.com> writes:
> On Thu, May 28, 2009 at 11:26 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> Kind of --- I am stuck because we don't auto-cast for index usage like
>> we do for function calls and operators, so I will just keep going and
>> disable tsvector.

> I was pretty stumped by what you meant by "auto-cast" but now I'm
> beginning to think what you're looking for are cross-type comparison
> operators? You could define a bunch of such operators which manually
> call the cast on one side and add them to the operator class. I'm not
> sure how to set up the operator class entries for GIN though.

No, what we need is a GIN (and probably GIST) opclass to support
old-style tsvectors.  The user-level operators aren't really an issue
because an implicit cast will get inserted in front of them when
necessary, but we don't support that for indexes.

People who want decent performance on partial match queries (or maybe
even *any* TS queries) are going to have to convert to the new format
anyway, though, so maybe this isn't something worth putting a whole lot
of work into.  It might be sufficient if the database conversion
succeeds but leaves the tsvector columns unusable until they're
converted.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: User-facing aspects of serializable transactions
Next
From: Greg Stark
Date:
Subject: Re: User-facing aspects of serializable transactions