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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:26:02
Message-ID: CAApHDvoKf1yM_7DV0jPmWbkuhuhNUGVEBSr+Ou-jLmnDeYA80g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 29 Sep 2020 at 11:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I wrote:
> > list_second_cell() does have uses, although I observe that they
> > are almost exclusively in locutions such as
> > for_each_cell(lc, rollups, list_second_cell(rollups))
> > to iterate over all-but-the-first elements of a list. I wonder if
> > we ought to come up with a better notation for that. I'm imagining
> > something like
> > for_each_from(lc, rollups, 1)
> > to start from list index 1. It looks like this would be marginally
> > more efficient, and perhaps more readable.
>
> 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().

> 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.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-09-28 23:40:54 Re: Planner making bad choice in alternative subplan decision
Previous Message Andy Fan 2020-09-28 23:13:00 Re: Partition prune with stable Expr