| 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: | Whole Thread | Raw Message | 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 |