Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
От | David Rowley |
---|---|
Тема | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |
Дата | |
Msg-id | CAApHDvrn=7wJ9Khb-6DdhZBv_gqre4kvymJYnZdd+Mfcok+E8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
|
Список | pgsql-hackers |
Thanks for 9d299a492. On Mon, 28 Sep 2020 at 15:35, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Poking around to count remaining uses of those inline functions, > I found a few places that should be using the macros instead, > and fixed them. After that, I notice that list_tail(), > list_third_cell(), and list_fourth_cell() are entirely unreferenced. > I'm hesitant to get rid of list_tail(), because it seems like it > could well be used by extensions. But I'd bet quite a bit that > list_third_cell() and list_fourth_cell() are not used anywhere > anymore. Should we get rid of them to shave a few microseconds > from compile times? I wouldn't object to the removal of list_third_cell() and list_fourth_cell(). I agree to your reasoning with last_tail(). It does seem more likely that someone would use it. Although, if you'd proposed to remove it too, I wouldn't have objected. It's not like it's hard to reimplement within an extension for any extensions that use it. Though, perhaps it would maybe be a shame if that was the sole thing we broke for them when they try compiling their extension in a year's time on the newly release PG14. David
В списке pgsql-hackers по дате отправления: