From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Obsolete reference to _bt_tuplecompare() within tuplesort.c |
Date: | 2014-10-10 06:58:30 |
Message-ID: | 54378396.9040401@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/10/2014 02:04 AM, Peter Geoghegan wrote:
> I found a reference made obsolete by commit 9e85183b, which is from
> way back in 2000.
>
> comparetup_index_btree() says:
>
> /*
> * This is similar to _bt_tuplecompare(), but we have already done the
> * index_getattr calls for the first column, and we need to keep track of
> * whether any null fields are present. Also see the special treatment
> * for equal keys at the end.
> */
>
> I think that this comment should simply indicate that the routine is
> similar to comparetup_heap(), except that it takes care of the special
> tie-break stuff for B-Tree sorts, as well as enforcing uniqueness
> during unique index builds. It should not reference _bt_compare() at
> all (which is arguably the successor to _bt_tuplecompare()), since
> _bt_compare() is concerned with a bunch of stuff highly specific to
> the B-Tree implementation (e.g. having a hard-wired return value for
> comparisons involving the first data item on an internal page).
Yeah. Want to write that into a patch?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Connor Wolf | 2014-10-10 07:03:56 | Re: [GENERAL] Understanding and implementing a GiST Index |
Previous Message | Amit Kapila | 2014-10-10 06:58:13 | Re: Scaling shared buffer eviction |