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 1jlTHC-0003ls-0I for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jun 2020 08:18:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTH9-0007f7-H1 for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jun 2020 08:18:27 +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 1jlTH8-0007et-Ks for pgsql-hackers@lists.postgresql.org; Wed, 17 Jun 2020 08:18:27 +0000 Received: from forward3-smtp.messagingengine.com ([66.111.4.237]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jlTH5-0008UQ-Go for pgsql-hackers@postgresql.org; Wed, 17 Jun 2020 08:18:25 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailforward.nyi.internal (Postfix) with ESMTP id 5D2711941E0D; Wed, 17 Jun 2020 04:18:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 17 Jun 2020 04:18:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vVNkF7XnZXQQIH5CayqZNqbTBO1ZRm9xH7ziWKpBn BU=; b=Z8up9aayC+iIG3NyoX2JMncIrGlLlOJHQXXGwykVVeGxk2hm6sizZJPUP swQBENJsUOldt8Wu9n19uDW+jo/ABVbidTK7Fza/uQQtIujWPeLmB2eIrktHMZrV CqVYvAAJZEJ1oBO00TjEfCjJiekxeNfb7jpDQ9iT0dxthofau3fElxEMX9y6B6vG CfefFBySi8uIo5D3x5SuEOiks5RVLxinyRgL1JmCbtbG0hkj6R64HoIP2o4GoeDI EdZFmNjKRGdYSl2mMm4ZJZ+pDlfa8zapv+AwCdo+a6D+nvBUeLJ5JcmAPLlfO3TL i8Vv5sKA116RXm8Yzu/nORiYPztag== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejvddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeehnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnug hquhgrughrrghnthdrtghomheqnecuggftrfgrthhtvghrnhepveeuteelvdeuudfggfev udegudfhvdekgeeufefhtdeguedugefhheeugeefhfeinecuffhomhgrihhnpedvnhguqh hurggurhgrnhhtrdgtohhmnecukfhppeelfedrvdegfedrudeluddrvdefkeenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvih hsvghnthhrrghuthesvdhnughquhgrughrrghnthdrtghomh X-ME-Proxy: Received: from april.pezone.net (p5df3bfee.dip0.t-ipconnect.de [93.243.191.238]) by mail.messagingengine.com (Postfix) with ESMTPA id 1D86E3061856; Wed, 17 Jun 2020 04:18:20 -0400 (EDT) Subject: Re: remove some STATUS_* symbols To: Michael Paquier References: <20200106063159.GQ3598@paquier.xyz> <20200110052332.GI1702@paquier.xyz> <4edc8a92-373c-1a4d-eded-6b342f0890dc@2ndquadrant.com> <20200116055001.GH3117@paquier.xyz> <3a4550d0-e899-b477-fd43-0745d18a4fc1@2ndquadrant.com> <20200612073045.GG3362@paquier.xyz> Cc: Robert Haas , pgsql-hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Wed, 17 Jun 2020 10:18:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200612073045.GG3362@paquier.xyz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-06-12 09:30, Michael Paquier wrote: > On Thu, Jun 11, 2020 at 03:55:59PM +0200, Peter Eisentraut wrote: >> On 2020-01-16 13:56, Robert Haas wrote: >>> IMHO, custom enums for each particular case would be a big improvement >>> over supposedly-generic STATUS codes. It makes it clearer which values >>> are possible in each code path, and it comes out nicer in the >>> debugger, too. >> >> Given this feedback, I would like to re-propose the original patch, attached >> again here. >> >> After this, the use of the remaining STATUS_* symbols will be contained to >> the frontend and backend libpq code, so it'll be more coherent. > > I am still in a so-so state regarding this patch, but I find the > debugger argument a good one. And please don't consider me as a > blocker. Okay, I have committed it. >> Add a separate enum for use in the locking APIs, which were the only >> user. > >> +typedef enum >> +{ >> + PROC_WAIT_STATUS_OK, >> + PROC_WAIT_STATUS_WAITING, >> + PROC_WAIT_STATUS_ERROR, >> +} ProcWaitStatus; > > ProcWaitStatus, and more particularly PROC_WAIT_STATUS_WAITING are > strange names (the latter refers to "wait" twice). What do you think > about renaming the enum to ProcStatus and the flags to PROC_STATUS_*? I see your point, but I don't think that's better. That would just invite someone else to use it for other process-related status things. We typically name enum constants like the type followed by a suffix. The fact that the suffix is similar to the prefix here is more of a coincidence. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services