Re: Review: B-Tree emulation for GIN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Review: B-Tree emulation for GIN
Date
Msg-id 24052.1238883910@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: B-Tree emulation for GIN  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
> [ fixes for the GIN stuff I complained about before ]

This all looks good to me, please apply.  One little suggestion: 
!         /* 
!          * entryRes array is used for:
!          * - as an argument for consistentFn
!          * - entry->curItem with corresponding key->entryRes[i] == false are greater 
!          *   than key->curItem, so next loop/call they should be renewed
!          *   by entryGetItem(). So, we need to set up an array before
!          *   checking of lossy page.
!          */

pgindent will reflow this comment block, since it's not at the left
margin.  To keep the formatting looking good you'll need to add /*--------

>> * I'd also like to come to some agreement about getting rid of the
>> fail-on-NULL-scankey problem in newScanKey().  As I noted in the
>> comment there, we could make that work cleanly if we are willing to
>> assume that all GIN-indexable operators are strict.  We already assume
>> the same for hash and btree operators, so it doesn't seem like a big
>> problem to do this, but I wonder if there are any objections.

> Agree.  I changed the GIN code, but don't know where is other places
> to change to fixate this agreement.

I don't think there is anything else that needs to be done for that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: monitoring-stats.html documentation
Next
From: Tom Lane
Date:
Subject: Re: Duplicate key value error