Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "Seki, Eiji" <seki(dot)eiji(at)jp(dot)fujitsu(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags
Date: 2017-02-15 21:57:54
Message-ID: 17528.1487195874@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-02-15 12:27:11 -0500, Robert Haas wrote:
>> I agree; also, many years ago a guy named Tom Lane told me that flags
>> argument should typically be declared as type "int". I've followed
>> that advice ever since.

> Why is that? I think uint makes a lot more sense for flags where the
> flags are individual bits that set/unset. Doing that with the sign bit
> isn't a good idea.

It would only matter if you got to the point of needing the sign bit
for a flag, which basically never happens for this sort of usage
(or if it does, you'd better be thinking about switching to int64
anyway). So the extra mental and typing load of choosing some other
type than plain old "int" isn't really justified, IMO.

Anyway the real point is that "int" is preferable to "uint8" which
was the original choice here. "uint8" unduly constrains the number
of flags you can add without an ABI break, and on many machines it's
more efficient to pass "int" function arguments than some other width.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message neha khatri 2017-02-15 22:51:59 Re: bytea_output vs make installcheck
Previous Message Tom Lane 2017-02-15 21:47:28 Re: Patch to implement pg_current_logfile() function