From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |
Date: | 2020-09-28 23:42:54 |
Message-ID: | 477797.1601336574@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 29 Sep 2020 at 11:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Concretely, I'm thinking about the attached.
> I had a look over this and I like it. It seems good as it allows
> consumers to choose N programmatically rather than be fixed into using
> list_second_cell() or list_fortysecond_cell().
Thanks for looking! Right now, if you want to start from a non-first
point in the list, you have to use for_each_cell (or else write out
a loop manually, but let's not). I'm not proposing to remove that
alternative, but there are surely cases where it's simpler or clearer
to use a list index instead of a ListCell pointer -- especially so if
the list index is a constant. So I think this is a pretty clear win
that simply failed to occur to me earlier.
>> I'm somewhat inclined to back-patch this into v13. The missing
>> const decoration seems arguably a bug, which we've missed noticing
>> only because of our generally lamentable under-usage of const.
>> And I think it'll be helpful for future back-patching if
>> for_each_from is available in all versions with the new List API.
> It does seem fairly low risk and having personally experienced
> backpatching pain, I understand your motivation to backpatch. I
> certainly wouldn't object to backpacking but will defer to your better
> judgement on whether you choose to or not.
A key point here is that everyplace I'm proposing to touch was already
changed in v13 (a fortiori, because list_second_cell wasn't there in v12).
So we can either have two different coding patterns in these areas, or
three. Two's better from a backpatching standpoint. The fact that
v13 is barely out the door also factors into this ... a year from now,
my judgment would probably be different.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-09-28 23:58:35 | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |
Previous Message | David Rowley | 2020-09-28 23:40:54 | Re: Planner making bad choice in alternative subplan decision |