Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)

<div class="gmail_quote">On Mon, Nov 28, 2011 at 3:00 AM, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="margin:00 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I see your point that we only need the penalty
valuesto be comparable<br /> for the same "new" value, but I don't think that really answers my<br /> objection,
becauseyou've had to lobotomize the logic.  As an example,<br /> if we have a new empty range to insert, and all the
existingroot-page<br /> entries are ordinary finite ranges, this code will throw up its hands<br /> and give them all
thesame 4.0 penalty value.  Surely it would be better<br /> to attempt to pick the smallest (narrowest) existing range.
 Butto do<br /> that, you have to pay attention to the subdiff value.<br /></blockquote></div>I believe it's a problem
ofthe current GiST interface. If using subdiff value as an penalty for insertion of empty range, we have to return 0
penaltyfor any entry with RANGE_CONTAIN_EMPTY flag. And for plain empty entry too without any chance to define priority
betweenthem. In my opinion solution is that penalty function should return vector of floats instead of single float.
Withcurrent GiST interface we have to do will solution of handling some cases better and some cases worse. For example,
GiSTfor boxes also suffers from interface limitation. In many papers I met recommendation to choose smallest box from
boxeswith same extention (it's not a rare situation to have multiple boxes with zero extention) for tuple insertion.
Butwith current interface, we can't implement it.<br /><br />------<br />With best regards,<br />Alexander Korotkov.<br
/>