David Rowley <david.rowley@2ndquadrant.com> writes:
> On Thu, 28 Feb 2019 at 09:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 0002 below does this. I'm having a hard time deciding whether this
>> part is a good idea or just code churn. It might be more readable
>> (especially to newbies) but I can't evaluate that very objectively.
> I'm less decided on this. Having this now means you'll need to break
> the signature of the macro the same way as you'll need to break
> lnext(). It's perhaps easier to explain in the release notes about
> lnext() having changed so that extension authors can go fix their code
> (probably they'll know already from compile failures, but ....). On
> the other hand, if the list_cell_is_last() is new, then there will be
> no calls to that in extensions anyway. Maybe it's better to do it at
> the same time as the List reimplementation to ensure nobody needs to
> change anything twice?
Yeah, I was considering the idea of setting up the macro as
"list_cell_is_last(list, cell)" from the get-go, with the first
argument just going unused for the moment. That would be a good
way to back-patch it if we go through with this. On the other hand,
if we end up not pulling the trigger on the main patch, that'd
look pretty silly ...
regards, tom lane
