Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKXOw-0004Ey-3Q for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Jan 2023 04:28:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pKXOu-0006By-0u for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Jan 2023 04:28:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKXOs-000664-R3 for pgsql-hackers@lists.postgresql.org; Wed, 25 Jan 2023 04:28:43 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKXOp-0005bs-EA for pgsql-hackers@postgresql.org; Wed, 25 Jan 2023 04:28:41 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id CFBBC3200947; Tue, 24 Jan 2023 23:28:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 24 Jan 2023 23:28:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1674620917; x=1674707317; bh=LUljKjuJrH QxU+sCTa3FtfPEQlvSXeo2rwDiDrdgLuk=; b=E6AOzK/tCmLK4dWmPK5N96cEUA a7LpOrqHlYOdL1E3K+yq2VUrbQiuvOuhBLl8fJ2oJsht4lPTl+MgJJp5XEbOzrqe 0+cRoRMKuiQXvAg55/XaouzFhl8C3DNe1BiUbSLJHkaevAzbyP4HxPHshjRSgtTc h8CnS/kV9vEpFQMiBt+iEGzfd6HMdxy9QNB0V7BfgOl6tfHTsaE52qQMNuJPHsTw D9x7N5GhAv+Rtk+lqme7ZvWinWw8jbnqBrIktaUlGvMARW5rR5giL2iSO23SyWhi YXCc6mCBk9HBHW9xveXoiSnURSzfRutN8/krWfVkfiYergnOTp00OpoHmREg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1674620917; x=1674707317; bh=LUljKjuJrHQxU+sCTa3FtfPEQlvS Xeo2rwDiDrdgLuk=; b=UFnocRHr2hK5yiZSj2Jnu9IeSV5uZrEAu7A5qIyHhlaZ ogJIB0+Fbo5p1di5tPHuK5nFbyNGEm0w2j51YaEbiYECeEpTtNNxB1T1feUN+z6+ xisYoIKv1q2Xb325xoZ24i79GDggszsvkmWQLrz+/ThrjaNiJM5sDWUsyMGaCaRM OMPcTZE3Awm3+yZL4dKGVzhnODwxryRkdLr6Ly7RDAahMsICEu7pbPzp1OCfZnvO hSkJO4SHQnlPg+aXfDOlbsVhSIXHUjGQ0VXUfhY4R/Tn2selpS4ukC8egcAl+WK0 mmDuZI8yLDLExF4fOjujFQJRx+rYdsRovWEIztCQqg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddvuddgjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesmhdtreertddtvdenucfhrhhomheptehnughr vghsucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrf grthhtvghrnhepkeeiueegvedugeeutdeifeffiedvgfeugeekhfeftdevfeekffelgfeg vefhudejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnughrvghssegrnhgrrhgriigvlhdruggv X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 Jan 2023 23:28:36 -0500 (EST) Date: Tue, 24 Jan 2023 20:28:35 -0800 From: Andres Freund To: Tom Lane , Noah Misch Cc: pgsql-hackers@postgresql.org, Peter Eisentraut , Andrew Dunstan Subject: Re: plpython vs _POSIX_C_SOURCE Message-ID: <20230125042835.y7ikaqwku73kwssc@awork3.anarazel.de> References: <20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de> <2265665.1674582915@sss.pgh.pa.us> <20230124190721.mi7l5c3n2tsrqjno@awork3.anarazel.de> <2320614.1674594966@sss.pgh.pa.us> <20230125014856.j3ndx2cftjxdvqul@awork3.anarazel.de> <20230125023246.trnwn42dnj3e4ikc@awork3.anarazel.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6igzfcdkhdodawxc" Content-Disposition: inline In-Reply-To: <20230125023246.trnwn42dnj3e4ikc@awork3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --6igzfcdkhdodawxc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On 2023-01-24 18:32:46 -0800, Andres Freund wrote: > > I ran out of energy to test on aix with xlc, I spent way more time on this > > than I have already. I'll pick it up later. > > Building in the background now. Also passes. Thus I think getting rid of the #undefines is the best plan going forward. Fewer complicated rules to follow => fewer rule violations. Patches attached. Greetings, Andres Freund --6igzfcdkhdodawxc Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-plpython-Avoid-the-need-to-redefine-printf-macros.patch" From eb3fb959b3db609db44437f783fc58cdb7f28e9f Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Tue, 24 Jan 2023 11:42:35 -0800 Subject: [PATCH v1 1/3] plpython: Avoid the need to redefine *printf macros Until now we undefined and then redefined a lot of *printf macros due to worries about conflicts with Python.h macro definitions. Current Python.h doesn't define any *printf macros, and older versions just defined snprintf, vsnprintf, guarded by #if defined(MS_WIN32) && !defined(HAVE_SNPRINTF). Thus we can replace the undefine/define section with a single #define HAVE_SNPRINTF 1 Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de --- src/pl/plpython/plpython.h | 48 +++----------------------------------- 1 file changed, 3 insertions(+), 45 deletions(-) diff --git a/src/pl/plpython/plpython.h b/src/pl/plpython/plpython.h index 2af0d04d1f8..2d18fc2dc1b 100644 --- a/src/pl/plpython/plpython.h +++ b/src/pl/plpython/plpython.h @@ -30,17 +30,10 @@ #undef _XOPEN_SOURCE /* - * Sometimes python carefully scribbles on our *printf macros. - * So we undefine them here and redefine them after it's done its dirty deed. + * Python versions <= 3.8 otherwise define a replacement, causing macro + * redefinition warnings. */ -#undef vsnprintf -#undef snprintf -#undef vsprintf -#undef sprintf -#undef vfprintf -#undef fprintf -#undef vprintf -#undef printf +#define HAVE_SNPRINTF 1 #if defined(_MSC_VER) && defined(_DEBUG) /* Python uses #pragma to bring in a non-default libpython on VC++ if @@ -63,41 +56,6 @@ #undef TEXTDOMAIN #define TEXTDOMAIN PG_TEXTDOMAIN("plpython") -/* put back our *printf macros ... this must match src/include/port.h */ -#ifdef vsnprintf -#undef vsnprintf -#endif -#ifdef snprintf -#undef snprintf -#endif -#ifdef vsprintf -#undef vsprintf -#endif -#ifdef sprintf -#undef sprintf -#endif -#ifdef vfprintf -#undef vfprintf -#endif -#ifdef fprintf -#undef fprintf -#endif -#ifdef vprintf -#undef vprintf -#endif -#ifdef printf -#undef printf -#endif - -#define vsnprintf pg_vsnprintf -#define snprintf pg_snprintf -#define vsprintf pg_vsprintf -#define sprintf pg_sprintf -#define vfprintf pg_vfprintf -#define fprintf pg_fprintf -#define vprintf pg_vprintf -#define printf(...) pg_printf(__VA_ARGS__) - /* * Used throughout, so it's easier to just include it everywhere. */ -- 2.38.0 --6igzfcdkhdodawxc Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0002-plpython-Stop-undefining-_POSIX_C_SOURCE-_XOPEN_S.patch" From 54f95177b0f32522862cc3589c587cbe3595304b Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Tue, 24 Jan 2023 19:03:36 -0800 Subject: [PATCH v1 2/3] plpython: Stop undefining _POSIX_C_SOURCE, _XOPEN_SOURCE We undefined them to avoid warnings about macro redefinitions. But we haven't fully followed the necessary include order, since at least 147c2482542, in 2011. Recently the combination of the include order rules not being followed and undefining _POSIX_C_SOURCE started to cause a compile failure, starting with 03023a2664f. Undefining _POSIX_C_SOURCE hides clock_gettime(), which is referenced in an inline function as of 03023a2664f, whereas it was a macro before. After seeing some evidence that undefining _POSIX_C_SOURCE et al isn't required, I tried to build postgres with plpython on most of our supported platforms (except DragonFlyBSD and Illumos, but similar systems were tested), with/without the #undefines. No compiler warning / behavioral difference. The oldest supported python version, 3.2, defines _POSIX_C_SOURCE to 200112L ad _XOPEN_SOURCE to 600, whereas newer versions of python use 200809L/700 respectively. As _POSIX_C_SOURCE/_XOPEN_SOURCE will default to the newer operating system on most platforms, it's possible that when using python 3.2 new warnings would be emitted - but that seems acceptable. Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de --- src/pl/plpython/plpython.h | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/src/pl/plpython/plpython.h b/src/pl/plpython/plpython.h index 2d18fc2dc1b..91f6f8d8607 100644 --- a/src/pl/plpython/plpython.h +++ b/src/pl/plpython/plpython.h @@ -12,23 +12,13 @@ #ifndef PLPYTHON_H #define PLPYTHON_H -/* - * Include order should be: postgres.h, other postgres headers, plpython.h, - * other plpython headers. (In practice, other plpython headers will also - * include this file, so that they can compile standalone.) - */ -#ifndef POSTGRES_H +/* postgres.h needs to be included before Python.h, as usual */ +#if !defined(POSTGRES_H) #error postgres.h must be included before plpython.h +#elif defined(Py_PYTHON_H) +#error Python.h must be included via plpython.h #endif -/* - * Undefine some things that get (re)defined in the Python headers. They aren't - * used by the PL/Python code, and all PostgreSQL headers should be included - * earlier, so this should be pretty safe. - */ -#undef _POSIX_C_SOURCE -#undef _XOPEN_SOURCE - /* * Python versions <= 3.8 otherwise define a replacement, causing macro * redefinition warnings. -- 2.38.0 --6igzfcdkhdodawxc--