From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |
Date: | 2020-09-27 21:08:42 |
Message-ID: | CAApHDvpo1zj9KhEpU2cCRZfSM3Q6XGdhzuAS2v79PH7WJBkYVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Over in [1] I complained to Tom that I thought he should use
list_nth() instead of linitial() and lsecond(). My reasoning was that
we already knew that the list contained 2 elements, and linitial() and
lsecond() do some additional checks and return NULL if there are fewer
than that amount of elements in the list, or so I thought. As it
turns out, due to the lfirst() dereferencing the returned pointer,
we'd just segfault if the list being too short and we got NULL.
Since there appears to be no actual safety reason to use those macros
in case your list is too small, it seems better just to use
lfirst(list_nth_cell(..., ...)). This saves doing the checks to see
if the list is NIL or too short. It seems nice to get rid of that
additional branching.
We can't just return list_nth() as some code still do things like:
linitial(list) = something;
and we obviously can't assign "something" to the return value of a
function call.
I've attached a patch which improves the macros.
I see on gcc9.3 this reduces the size of the postgres binary by about
16KB: 9027296 to 9011320.
I'm a bit unsure about llast()'s new double evaluation of the list.
Perhaps I can add a new inline function named list_last_cell() to get
around that... Or maybe it doesn't matter. I'm not quite sure what's
best there.
David
Attachment | Content-Type | Size |
---|---|---|
0001-Improve_pg_list_macros.patch | application/octet-stream | 2.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2020-09-27 21:35:38 | Re: Partition prune with stable Expr |
Previous Message | David Rowley | 2020-09-27 20:46:37 | Re: Partition prune with stable Expr |