|From:||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>, Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: Re: Email to hackers for test coverage|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Aug 27, 2019 at 03:57:20PM +0800, movead(dot)li(at)highgo(dot)ca wrote:
> I think your way is much better, so I change the patch and it is
> 'regression_20190827.patch' now.
Thanks for the new patch, I have committed the part for float4.
> 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.
But I am not sold to that part yet, for three reasons:
- numeric is not a test suite designed for sorting, and hijacking it
to do so it not a good approach.
- it would be good to get coverage for the two extra code paths while
we are on it with NULL datums.
- There is no need for two INSERT queries, I am getting the same
coverage with only one.
Please note that I have not looked in details where we could put that,
but perhaps Robert and Peter G who worked on 4ea51cd to add support
for abbreviated keys have some ideas, so I am adding them in CC for
|Next Message||Michael Paquier||2019-08-28 05:02:08||Re: REINDEX filtering in the backend|
|Previous Message||Peter Geoghegan||2019-08-28 03:19:43||Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.|