Jack Orenstein <jao@xxxxxxxxxxxx> writes: > I am defining a new type, FooBar, and trying to create a GIN index for it. > Everything is working well without the index. FooBar values are getting > into a table, and being retrieved and selected correctly. But I'm getting a > crash when I add a GIN index on a column of type FooBar. > Here is the operator class: > create operator class foobar_ops > default for type foobar using gin > as > operator 1 @@, > function 1 foobar_cmp(bigint, bigint), > function 2 foobar_item_to_keys(foobar, internal), > function 3 foobar_query_to_keys(foobar, internal, int2, internal, > internal), > function 4 foobar_match(internal, int2, anyelement, int4, internal, > internal), > function 5 foobar_partial_match(foobar, foobar, int2, internal); Hmm, don't you want a "STORAGE bigint" clause in there? > And the implementation: > int64_t* keys = (int64_t*) palloc(sizeof(int64_t)); As a general rule, ignoring the conventions about how to use Datums is a good way to cause yourself pain. It doesn't look like what you've shown us so far is directly broken ... as long as you don't try to run it on 32-bit hardware ... but bugs could easily be lurking nearby. More, the fact that this code looks nothing like standard coding for the task is not making your life easier, because you can't easily compare what you've done to other functions. It'd be much wiser to write this as Datum *keys = (Datum *) palloc(sizeof(Datum) * whatever); and then use Int64GetDatum() to convert your integer key values to Datums. Yes, I'm well aware that that macro is physically a no-op (... on 64-bit hardware ...) but you're best advised to not rely on that, but think of Datum as a physically distinct type. regards, tom lane
