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