Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros

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

In response to

Responses

Browse pgsql-hackers by date

  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