Re: First version of multi-key index support for GiST - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: First version of multi-key index support for GiST
Date
Msg-id 3B160763.7000506@stack.net
Whole thread Raw
In response to First version of multi-key index support for GiST  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
> What is the point of the macro
> 
> #define ATTGET(itup, Rel, i, isnull ) ((char*)( \
>         ( IndexTupleSize(itup) == sizeof(IndexTupleData) ) ? \
>                 *(isnull)=true, NULL \
>             : \
>             index_getattr(itup, i, (Rel)->rd_att, isnull) \
>     ))
> 
> It appears to me that index_getattr should handle an all-NULL index
> tuple just fine by itself --- certainly the btree code expects it to.
> So I do not see the reason for this extra layer on top of it.



You are right. It can be removed or replaced to
#define ATTGET(itup, Rel, i, isnull ) (char*)( index_getattr(itup, i, (Rel)->rd_att, isnull) )

The point was that in gist_tuple_replacekey (called from gistPageAddItem) key may be 


replaced by null value, but flag itup->t_info & INDEX_NULL_MASK is not set. 


Now we don't use gistPageAddItem (


see http://fts.postgresql.org/db/mw/msg.html?mid=118707).

This is our oversight.


-- 
Teodor Sigaev
teodor@stack.net




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Imperfect solutions
Next
From: Kovacs Zoltan
Date:
Subject: ERROR: cache lookup for proc 43030134 failed