Re: remove some STATUS_* symbols

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove some STATUS_* symbols
Date: 2020-06-12 07:30:45
Message-ID: 20200612073045.GG3362@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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_*?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-06-12 07:48:32 Re: doc review for v13
Previous Message Andrew Gierth 2020-06-12 07:25:52 Re: Infinities in type numeric