From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tuplesort.c's copytup_index() is dead code |
Date: | 2016-06-24 21:26:18 |
Message-ID: | CAM3SWZR9HcXoZ9jfkn4oGppBhrWedDeoHjAAw0TVAtC0RJ6=Yw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 24, 2016 at 2:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Uh, why? It's not a large amount of code and it seems like removing
> it puts a fair-size hole in the symmetry of tuplesort's capabilities.
It's not a small amount of code either.
Removing the code clarifies the division of labor between COPYTUP()
routines in general, their callers (tuplesort_putheaptuple() and
tuplesort_puttupleslot() -- which are also puttuple_common() callers),
and routines that are similar to those caller routines (in that they
at least call puttuple_common()) that do not call COPYTUP()
(tuplesort_putdatum(), and now tuplesort_putindextuplevalues()).
I believe that this has value. All the extra boilerplate code misleads.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2016-06-24 22:12:05 | Re: Bug in to_timestamp(). |
Previous Message | Tom Lane | 2016-06-24 21:18:20 | Re: tuplesort.c's copytup_index() is dead code |