GIST_LEAF() causes error in GiST methods union and penalty - Mailing list pgsql-hackers

From Marios Vodas
Subject GIST_LEAF() causes error in GiST methods union and penalty
Date
Msg-id DUB002-W1237D59E443B9BA677F2594DEFC0@phx.gbl
Whole thread Raw
List pgsql-hackers
<div dir="ltr">Hello all,<br /> <br />I tried to use GIST_LEAF() macro in union and penalty methods of GiST and it
failswith a terrible error when I run "CREATE INDEX" (in windows postgresql daemon shuts down). On the other hand,
GIST_LEAF()works as expected in consistent, distance, and picksplit methods. My leaf nodes contain the indexed column
datatype whilst the non-leaf nodes have a different (internal) data type that is only known in C level (all types are
fixed-length).I don't specify the "STORAGE" parameter in "CREATE OPERATOR CLASS ... USING gist" since the leaves are
exactlyof the same type as the column. Moreover, compress and decompress don't do anything just return the pointer they
received(only compress checks for NULLs since there should be no NULLs in the column in my case).<br />I also noticed
inthe documentation that in compress we determine if the page is leaf or not by using "if (entry->leafkey)" instead
ofGIST_LEAF() macro.<br /> <br /><ul><li>What is the difference between "if (entry->leafkey)" and GIST_LEAF() and
whenshould each one be used?</ul> <br />I believe there are some conventions that GiST takes into account w.r.t. when
itcalls union and penalty and with what parameters, but I am not sure if they are right. So, I think that
"<strong>union</strong>"<strong></strong>is called only in leaf pages so the GistEntryVector parameter contains always
leafenties of my leaf data type (I am calling this an assumption because GIST_LEAF() breaks in union and "if
(entry->leafkey)"always returns false which doesn't sound logical and makes me think that entry->leafkey should
notbe used). Also, the "GISTENTRY *origentry" of "<strong>penalty</strong>"<strong> </strong>is always of the non-leaf
datatype because it contains non-leaf entries whilst "GISTENTRY *newentry" is always of the leaf data type.<br /> <br
/><ul><li>Arethe previous thoughts-assumptions correct? This is very important to me because I have to handle different
leaf/non-leafdata types.</ul> <br /><ul><li>And one last question, the two parameters of the "<strong>same</strong>"
methodare always of the non-leaf data type?</ul> <br />Kind regards,<br />Marios Vodas<br /></div> 

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq
Next
From: Amit Kapila
Date:
Subject: Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq