To: Hannu Krosing <hannu@tm.ee>
cc: Oleg Bartunov <oleg@sai.msu.su>, Bruce Momjian <pgman@candle.pha.pa.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Who is a maintainer of GiST code ? 
In-reply-to: <3A3EA5F2.DF22E9E6@tm.ee> 
References: <Pine.GSO.3.96.SK.1001218233711.7544B-100000@ra>
	<1642.977173813@sss.pgh.pa.us> <3A3EA5F2.DF22E9E6@tm.ee>
Comments: In-reply-to Hannu Krosing <hannu@tm.ee>
	message dated "Tue, 19 Dec 2000 02:04:02 +0200"
Date: Mon, 18 Dec 2000 19:25:38 -0500
Message-ID: <2483.977185538@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Hannu Krosing <hannu@tm.ee> writes:
> and I can't see why btree stores them (as it seems to do judging by the 
> index file size) - at least it does not use it for searching for "IS
> NULL"

That's another thing that needs improvement ;-).  Seems to me it should
be able to do that.

The reason why btree *has* to be able to deal with null entries is to
cope with multi-column indexes; you don't want it refusing to index a
row at all just because some of the columns are null.  The others don't
currently handle multi-column indexes, so they're not really forced
to deal with that issue.