Re: Propose a new function - list_is_empty

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Propose a new function - list_is_empty
Date: 2022-08-16 14:03:57
Message-ID: 1121750.1660658637@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 15, 2022 at 9:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> That's because the *correct* way to write it is either "alist == NIL"
>> or just "!alist".

> I think the alist == NIL (or alist != NIL) style often makes the code
> easier to read. I recommend we standardize on that one.

I have a general preference for comparing to NIL because (as Daniel
noted nearby) it reminds you of what data type you're dealing with.
However, I'm not up for trying to forbid the bare-boolean-test style
altogether. It'd be near impossible to find all the instances;
besides which we don't insist that other pointer checks be written
as explicit comparisons to NULL --- we do whichever of those seems
clearest in context. So I'm happy for this patch to leave either
of those existing usages alone. I agree though that while simplifying
list_length() calls, I'd lean to using explicit comparisons to NIL.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2022-08-16 14:26:33 Re: Patch proposal: New hooks in the connection path
Previous Message Christoph Berg 2022-08-16 13:56:45 Re: pg_receivewal and SIGTERM