Re: Fixing MSVC's inability to detect elog(ERROR) does not return - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing MSVC's inability to detect elog(ERROR) does not return
Date
Msg-id 1443736.1758084349@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing MSVC's inability to detect elog(ERROR) does not return  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 17 Sept 2025 at 16:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It absolutely stands for "predicate".  That's an ancient Lisp-ism.

> Thanks for the confirmation. I'm happy enough to leave the _p in
> there, but at the same time, I don't see the particular reason to
> follow some ancient Lisp rule.

I'm just saying that that's surely where the gcc crew got it from.
I do agree with Peter that we should follow that convention within
the narrow realm of compiler intrinsics; but I'm not arguing for
running around and renaming random PG functions to something_p.

As long as we're delving into weeds: we have another project
convention for "_P", which is terminal symbols in our grammar such
as NULL_P.  Clearly, that "P" is not for "predicate"; I suppose it
should be read as "parse" or "parser".  Given that large parts of
original POSTGRES were written in Lisp, it's a tad hard to believe
that whoever chose those names had not heard of the "predicate"
convention.  I guess he/she figured that it didn't matter because
there'd be very little overlap or scope for confusion, and that
seems to have been borne out over time.

            regards, tom lane



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Logical Replication of sequences
Next
From: David Rowley
Date:
Subject: Make TID Scans recalculate the TIDs less often