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
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 c
On 2020-01-16 13:56, Robert Haas wrote:
On Thu, Jan 16, 2020 at 12:50 AM Michael Paquier wrote:
Thanks, that looks fine. I am still not sure whether the second patch
adding an enum via ProcWaitStatus improves the code readability
though, so my take would be to discard it for now. Perhaps othe
On Thu, Jan 16, 2020 at 12:50 AM Michael Paquier wrote:
> Thanks, that looks fine. I am still not sure whether the second patch
> adding an enum via ProcWaitStatus improves the code readability
> though, so my take would be to discard it for now. Perhaps others
> think differently, I don't know.
At Thu, 16 Jan 2020 14:50:01 +0900, Michael Paquier wrote
in
> On Sat, Jan 11, 2020 at 08:14:17AM +0100, Peter Eisentraut wrote:
> > OK, pushed as it was then.
>
> Thanks, that looks fine. I am still not sure whether the second patch
> adding an enum via ProcWaitStatus improves the code readab
On Sat, Jan 11, 2020 at 08:14:17AM +0100, Peter Eisentraut wrote:
> OK, pushed as it was then.
Thanks, that looks fine. I am still not sure whether the second patch
adding an enum via ProcWaitStatus improves the code readability
though, so my take would be to discard it for now. Perhaps others
t
On 2020-01-10 06:23, Michael Paquier wrote:
On Thu, Jan 09, 2020 at 11:15:08AM +0100, Peter Eisentraut wrote:
You mean put he subsequent GrantLock() calls into LockCheckConflicts()? That
would technically save some duplicate code, but it seems weird, because
LockCheckConflicts() is notionally a
On Thu, Jan 09, 2020 at 11:15:08AM +0100, Peter Eisentraut wrote:
> You mean put he subsequent GrantLock() calls into LockCheckConflicts()? That
> would technically save some duplicate code, but it seems weird, because
> LockCheckConflicts() is notionally a read-only function that shouldn't
> chang
On 2020-01-06 07:31, Michael Paquier wrote:
On Sun, Dec 29, 2019 at 11:33:34AM +0100, Peter Eisentraut wrote:
Attached are two patches to remove these two symbols. STATUS_FOUND can be
replaced by a simple bool. STATUS_WAITING is replaced by a separate enum.
Patch 0001 looks good to me, but I
On Sun, Dec 29, 2019 at 11:33:34AM +0100, Peter Eisentraut wrote:
> Attached are two patches to remove these two symbols. STATUS_FOUND can be
> replaced by a simple bool. STATUS_WAITING is replaced by a separate enum.
Patch 0001 looks good to me, but I got to wonder why the check after
waitMask
I have found the collection of STATUS_* defines in c.h a bit curious.
There used to be a lot more even that have been removed over time.
Currently, STATUS_FOUND and STATUS_WAITING are only used in one group of
functions each, so perhaps it would make more sense to remove these from
the global n
11 matches
Mail list logo
