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 22:37:52
Message-ID: 474161.1601332672@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. This does seem simpler.
It reduces the size of the executable by about 560 bytes on
my machine, or 46 bytes per usage, which isn't bad. (Note: this
is in an assert-enabled build, might be different otherwise.)
I didn't try to measure performance changes, but it should be for
the better.

Looking at the remaining instances of for_each_cell, I see several
where it seems like it'd be simpler and clearer to use for_each_from.
But for the moment I confined myself to changing just the instances
following the pattern above.

I noticed while messing with this that I'd neglected to const-ify
the support functions for for_each_cell() and for_both_cell(),
so this fixes that too.

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.

regards, tom lane

Attachment Content-Type Size
introduce-for_each_from.patch text/x-diff 7.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-09-28 22:47:34 Re: Planner making bad choice in alternative subplan decision
Previous Message Masahiko Sawada 2020-09-28 22:36:54 Re: Dumping/restoring fails on inherited generated column