Re: Re: Email to hackers for test coverage

From: "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>
To: "Michael Paquier" <michael(at)paquier(dot)xyz>
Cc: ibrar(dot)ahmad <ibrar(dot)ahmad(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Re: Email to hackers for test coverage
Date: 2019-08-27 07:57:20
Message-ID: 2019082715571842080624@highgo.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Tue, 27 Aug 2019 14:07:48 +0800 michael(at)paquier(dot)xyz wrote:
> There is a section in float4.sql which deals with overflow and
> underflow, so wouldn't it be better to move the tests there? You
> could just trigger the failures with that:
> =# insert into float4_tbl values ('-10e-70'::float8);
> ERROR: 22003: value out of range: underflow
> LOCATION: check_float4_val, float.h:145
> =# insert into float4_tbl values ('-10e70'::float8);
> ERROR: 22003: value out of range: overflow
> LOCATION: check_float4_val, float.h:140
> I would also test all four patterns: 10e70, 10e-70, -10e70, -10e-70.

I think your way is much better, so I change the patch and it is
'regression_20190827.patch' now.

> For the numeric part, this improves the case of
> ApplySortAbbrevFullComparator() where both values are not NULL. Could
> things be done so as the other code paths are fully covered? One
> INSERT is fine by the way to add the extra coverage.
There are code lines related to NULL values in
ApplySortAbbrevFullComparator(), but I think the code lines for
comparing a NULL and a NOT NULL can be never reached, because it is
handled in ApplySortComparator() which is called before
ApplySortAbbrevFullComparator(). So I think it is no use to INSERT
a NULL value.

--
Movead

Attachment Content-Type Size
regression_20190827.patch application/octet-stream 5.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Asif Rehman 2019-08-27 08:19:19 Re: pgbench - allow to create partitioned tables
Previous Message Richard Guo 2019-08-27 07:56:59 Re: A problem about partitionwise join