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 [1] https://www.postgresql.org/message-id/caaphdvqeh8jeqmjpcftghd_zu2s03novh2srejd+snlza8m...@mail.gmail.com
0001-Improve_pg_list_macros.patch
Description: Binary data
