pgsql: Rely on __func__ being supported
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t228884psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 29, 2026 at 12:54 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t228884_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t228884_2 && git checkout t228884_2Patchset v2 (message #2) is on t228884_2
Rely on __func__ being supported
Previously we fell back to __FUNCTION__ and then NULL. As __func__ is in C99
that shouldn't be necessary anymore.
Solution.pm defined HAVE_FUNCNAME__FUNCTION instead of
HAVE_FUNCNAME__FUNC (originating in 4164e6636e2), as at some point in the past
MSVC only supported __FUNCTION__. Our minimum version supports __func__.
Reviewed-By: Thomas Munro <thomas.munro@gmail.com>
Discussion: /messages/by-id/20220807012914.ydz73yte6j3coulo@awork3.anarazel.de
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/320f92b744b44f961e5d56f5f21de003e8027a7f
Modified Files
--------------
config/c-compiler.m4 | 26 -----------------
configure | 61 ---------------------------------------
configure.ac | 1 -
src/backend/storage/lmgr/s_lock.c | 2 +-
src/include/c.h | 11 -------
src/include/pg_config.h.in | 6 ----
src/include/storage/s_lock.h | 4 +--
src/include/utils/elog.h | 4 +--
src/tools/msvc/Solution.pm | 2 --
9 files changed, 5 insertions(+), 112 deletions(-)
On 2022-Aug-07, Andres Freund wrote:
Rely on __func__ being supported
Previously we fell back to __FUNCTION__ and then NULL. As __func__ is in C99
that shouldn't be necessary anymore.Solution.pm defined HAVE_FUNCNAME__FUNCTION instead of
HAVE_FUNCNAME__FUNC (originating in 4164e6636e2), as at some point in the past
MSVC only supported __FUNCTION__. Our minimum version supports __func__.
I'd rather we keep PG_FUNCNAME_MACRO defined to __func__ ... it costs us
nothing. Would anybody oppose that?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Hi,
On 2022-08-07 19:40:14 +0200, Alvaro Herrera wrote:
I'd rather we keep PG_FUNCNAME_MACRO defined to __func__ ... it costs us
nothing. Would anybody oppose that?
I'm fine with re-adding the macro, as long as we don't re-add in-tree users.
Greetings,
Andres Freund
Hello
On 2022-Aug-07, Andres Freund wrote:
On 2022-08-07 19:40:14 +0200, Alvaro Herrera wrote:
I'd rather we keep PG_FUNCNAME_MACRO defined to __func__ ... it costs us
nothing. Would anybody oppose that?I'm fine with re-adding the macro, as long as we don't re-add in-tree users.
After further thinking, I conclude there's no need for this. It's quite
easy to add a "#ifndef PG_FUNCNAME_MACRO" stanza in third-party code if
needed, and just rely on __func__ otherwise.
Thanks
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/