Skip site navigation (1) Skip section navigation (2)

Re: First version of multi-key index support for GiST

From: Teodor Sigaev <teodor(at)stack(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: First version of multi-key index support for GiST
Date: 2001-05-31 08:57:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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 (


This is our oversight.


Teodor Sigaev

In response to

pgsql-hackers by date

Next:From: Kovacs ZoltanDate: 2001-05-31 12:47:26
Subject: ERROR: cache lookup for proc 43030134 failed
Previous:From: EricDate: 2001-05-31 05:42:41
Subject: SQL( "if ...exists...),how to do it in the PostgreSQL?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group