Christopher Murtagh <christopher.murtagh@mcgill.ca> writes:
> On Fri, 2003-08-08 at 16:08, Tom Lane wrote:
>> You should not be using the 7.2 methods anymore --- there is a CREATE
>> OPERATOR CLASS, use that instead. (See the contrib gist classes for
>> examples.)
> I'm having the same problem as Dmitry, but I've been unable to find a
> solution. I've looked everywhere googleable for info on setting up GiST
> indexes, but haven't found any info that doesn't look like post-doc
> papers on the theory of indexability.
That's about what there is AFAIK :-(. GiST suffers from a horrible lack
of documentation other than the original academic papers, which is one
of the reasons it's still not mainstream (although I'm not entirely sure
which is cause and which is effect here...)
However, if you have a working 7.2 opclass definition, it shouldn't be
that hard to make it into a 7.3 CREATE OPERATOR CLASS command. Compare
the 7.2 and 7.3 versions of any of the contrib GiST modules' sql.in
files, and all should become reasonably clear. The same basic
information is being supplied in both cases (operator names and strategy
numbers), 7.3 just does it with a much higher-level notation. For
instance, this part of 7.2's contrib/cube/cube.sql.in:
-- cube_left
INSERT INTO pg_amop (amopclaid, amopstrategy, amopreqcheck, amopopr)
SELECT opcl.oid, 1, false, c.opoid
FROM pg_opclass opcl, gist_cube_ops_tmp c
WHERE
opcamid = (SELECT oid FROM pg_am WHERE amname = 'gist')
and opcname = 'gist_cube_ops'
and c.oprname = '<<';
is replaced by a single line in 7.3's CREATE OPERATOR CLASS command:
OPERATOR 1 << ,
In particular look at this diff:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/contrib/cube/cube.sql.in.diff?r1=1.4&r2=1.5
You might also want to study the docs for the pg_opclass, pg_amop,
and pg_amproc system catalogs, to clarify what the original code was
doing.
regards, tom lane