From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rob Sargent <rsargent(at)xmission(dot)com> |
Cc: | Forums postgresql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: gin index trouble |
Date: | 2017-10-30 14:35:36 |
Message-ID: | 18063.1509374136@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Rob Sargent <rsargent(at)xmission(dot)com> writes:
> I’ve hit this same message
> Caused by: org.postgresql.util.PSQLException: ERROR: right sibling of GIN page is of different type
> in a couple of contexts and I’m starting to get worried.
If you can make a test case that (eventually) hits that, we'd be
interested to see it ...
> and I um, er, enabled gin on uuid by copying from a thread in this list, as follows:
> create operator class _uuid_ops
> default for type _uuid
> using gin as
> operator 1 &&(anyarray, anyarray)
> ,operator 2 @>(anyarray, anyarray)
> ,operator 3 <@(anyarray, anyarray)
> ,operator 4 =(anyarray, anyarray)
> ,function 1 uuid_cmp(uuid, uuid)
> ,function 2 ginarrayextract(anyarray, internal, internal)
> ,function 3 ginqueryarrayextract(anyarray, internal, smallint, internal, internal, internal, internal)
> ,function 4 ginarrayconsistent(internal, smallint, anyarray, integer, internal, internal, internal, internal)
> ,storage uuid;
You should not have needed to do that, I think, as the standard
anyarray GIN opclass should've handled it. Having said that,
I don't immediately see anything broken about this definition,
so it seems like it should've worked.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-10-30 14:35:43 | Re: starting PG command line options vs postgresql.con |
Previous Message | Alexander Farber | 2017-10-30 14:21:11 | Re: Comparing epoch to timestamp |