Re: Fixing MSVC's inability to detect elog(ERROR) does not return

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-17T04:45:49Z
Lists: 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



Commits

  1. Rename pg_builtin_integer_constant_p to pg_integer_constant_p

  2. Teach MSVC that elog/ereport ERROR doesn't return