Re: Fixing GIN for empty/null/full-scan cases

David Wheeler <david@kineticode.com>

From: "David E. Wheeler" <david@kineticode.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2011-01-13T00:08:22Z
Lists: pgsql-hackers
Tom,

On Jan 8, 2011, at 9:41 PM, Tom Lane wrote:

> "David E. Wheeler" <david@kineticode.com> writes:
>> On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
>>> Well, actually, I just committed it.  If you want to test, feel free.
>>> Note that right now only the anyarray && <@ @> operators are genuinely
>>> fixed ... I plan to hack on tsearch and contrib pretty soon though.
> 
>> Hrm, the queries I wrote for this sort of thing use intarray:
>>    WHERE blah @@ '(12|14)'::query_int
>> That's not done yet though, right?
> 
> intarray is done now, feel free to test ...

Thanks, working on it now. I'm restoring a dump from 8.4, but got these erors:

pg_restore: [archiver (db)] Error from TOC entry 3227; 2616 46485 OPERATOR CLASS gin__int_ops postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  function ginarrayextract(anyarray, internal) does not exist
    Command was: CREATE OPERATOR CLASS gin__int_ops
    FOR TYPE integer[] USING gin AS
    STORAGE integer ,
    OPERATOR 3 &&(integer[],int...
pg_restore: [archiver (db)] could not execute query: ERROR:  operator class "contrib.gin__int_ops" does not exist for access method "gin"
    Command was: ALTER OPERATOR CLASS contrib.gin__int_ops USING gin OWNER TO postgres;
pg_restore: [archiver (db)] Error from TOC entry 3254; 3600 16245434 TEXT SEARCH DICTIONARY en_mls_20101103 postgres

Did a signature change or something? Is there something that needs a compatibility interface of some kind?

Thanks,

David