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 1kVKUH-0000lj-O3 for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Oct 2020 20:13:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kVKUF-0005vY-Iz for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Oct 2020 20:13:31 +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 1kVKUF-0005se-Bq for pgsql-hackers@lists.postgresql.org; Wed, 21 Oct 2020 20:13:31 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVKUC-00038P-Rb for pgsql-hackers@postgresql.org; Wed, 21 Oct 2020 20:13:30 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id BA3D358059D; Wed, 21 Oct 2020 16:13:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 21 Oct 2020 16:13:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ApNVCvaAeO5ELjUbS T6kFrEv8nPGJb4SgN5VOCDdyxY=; b=CA3SeiSKH9nopeQ05SiPntvDOtsiA/bI+ jkPLEB0q0jdjN6ioZ0ZZv7106xgbv8LHTn+yGCwdDqEooEu5FAxHd/JRrOvO7Vr5 U8HnhOLB/Mv4BQO+riH1ItgZgJzHiZDOf6pWTlP+Tyo4TvJasc5DXPUETD30xi8c yR5GUMYMuSRAPy5lrMgLrSgavOwjDVcsVK3X/iNxm74JszgprqEIXdK6zkMRHP2k WyW/ZQeI0F00HloqT7TFnGj2JXXMHfI4KRUw3pKPIyuLQNP2LkOEzZSTrMtnzTVA ihw9i+DeFIB4sDPEuGFD54KL83nFFumXp++o9cILLgjrnHVsx3StA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeehgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggujggfsehttdertddtredvnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeevgfelveegueejgefhgeetgefhgeehieefheehleetteei udeiiefhgffgheffteenucfkphepudeltddrleehrdduledrudegkeenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.148]) by mail.messagingengine.com (Postfix) with ESMTPA id 412543064682; Wed, 21 Oct 2020 16:13:25 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id B86322A150F; Wed, 21 Oct 2020 17:13:22 -0300 (-03) Date: Wed, 21 Oct 2020 17:13:22 -0300 From: Alvaro Herrera To: Robert Haas Cc: Mark Dilger , Peter Geoghegan , "Andrey M. Borodin" , Stephen Frost , Michael Paquier , Amul Sul , Dilip Kumar , Andres Freund , Tom Lane , PostgreSQL-development Subject: Re: new heapcheck contrib module Message-ID: <20201021201322.GA1245@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Oct-21, Robert Haas wrote: > On Wed, Oct 7, 2020 at 9:01 PM Mark Dilger wrote: > > This next version, attached, has the acl checking and associated documentation changes split out into patch 0005, making it easier to review in isolation from the rest of the patch series. > > > > Independently of acl considerations, this version also has some verbiage changes in 0004, in response to Andrey's review upthread. > > I was about to commit 0001, after making some cosmetic changes, when I > discovered that it won't link for me. I think there must be something > wrong with the NLS stuff. My version of 0001 is attached. The error I > got is: Hmm ... I don't think we have translation support in contrib, do we? I think you could solve that by adding a "#undef _, #define _(...) (...)" or similar at the top of the offending C files, assuming you don't want to rip out all use of _() there. TBH the usage of "translation:" comments in this patch seems over-enthusiastic to me.