RE: BUG #15228: pgbench custom script numbering off-by-one - Mailing list pgsql-bugs

From Fabien COELHO
Subject RE: BUG #15228: pgbench custom script numbering off-by-one
Date
Msg-id alpine.DEB.2.21.1806060410540.10347@lancre
Whole thread Raw
In response to RE: BUG #15228: pgbench custom script numbering off-by-one  (Steven Winfield <Steven.Winfield@cantabcapital.com>)
List pgsql-bugs
Hello Steven,

There were some hesitations when developing this feature for 9.6, with a 
transition from starting from 0 to 1 on submission v9, without clear 
outside input in the discussion to which was better, if any.

The rational for starting from 1 in the stdout report is that I felt, and 
still feel, that it is more user/human friendly this way.

The 0-numbering for the log was pre-existing and as tools/scripts exist to 
process that, changing it is best avoided, and it is for machines anyway.

So my 0.02€:

IMO the minimum fuss is to let it as a feature, which it is, and just 
explicitely document it, so I'm on Tom's line here. See attached patch as 
an attempt to do that. Could be backpatched up to 9.6.

I could also be okay with starting from 0 as well, sure, but I like 
human-friendlyness so I would not bother.

>> So possibly we could resolve it by using 0-based numbering in the 
>> human-readable output, but that would confuse things too perhaps.
>>
>> Maybe we should just document it.
>
> Changing the human readable log, plus documentation, might be fair game 
> for a new major version. If so, I think the only changes required are:

Sure.

-- 
Fabien.
Attachment

pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BUG #15225: [XX000] ERROR: invalid DSA memory alloc request size1073741824 / Where: parallel worker
Next
From: "K S, Sandhya (Nokia - IN/Bangalore)"
Date:
Subject: psql crashes found when executing slash commands