| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Refactoring: join MakeSingleTupleTableSlot() and MakeTupleTableSlot() |
| Date: | 2021-10-23 23:33:12 |
| Message-ID: | YXSbuDQvyqaWJUL6@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 22, 2021 at 04:39:37PM +0300, Aleksander Alekseev wrote:
> I propose keeping only one of these procedures to simplify navigating
> through the code and debugging, and maybe saving a CPU cycle or two. A
> search for MakeTupleTableSlot produced 8 matches across 2 files, while
> MakeSingleTupleTableSlot is used 41 times across 26 files. Thus the
> proposed patch removes MakeTupleTableSlot and keeps
> MakeSingleTupleTableSlot to keep the patch less invasive and simplify
> backporting of the other patches. Hopefully, this will not complicate
> the life of the extension developers too much.
To make the life of extension developers easier, we could as well have
a compatibility macro so as anybody using MakeTupleTableSlot() won't
be annoyed by this change. However, looking around, this does not
look like a popular API so I'd be fine with your change as proposed.
Other opinions?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-10-23 23:41:52 | Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). |
| Previous Message | Michael Paquier | 2021-10-23 23:10:44 | Re: pg_receivewal starting position |