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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fixing MSVC's inability to detect elog(ERROR) does not return
Date: 2025-09-17 04:45:49
Message-ID: 1443736.1758084349@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 17 Sept 2025 at 16:03, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-09-17 04:59:51 Make TID Scans recalculate the TIDs less often
Previous Message shveta malik 2025-09-17 04:36:41 Re: Logical Replication of sequences