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
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 |