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
-
Rename pg_builtin_integer_constant_p to pg_integer_constant_p
- 8e2acda2b098 19 (unreleased) landed
-
Teach MSVC that elog/ereport ERROR doesn't return
- 59c2f03d1ece 19 (unreleased) landed