[develop] Catchment functions when negative distance do not have a standardized behaviour

[sakirr05]

Problem

Follow up of #3091, same tests but on develop (4.1.0-dev), tested on PostgreSQL 17.9 / Ubuntu 24.04.

Three of the four catchment functions are already fixed on develop, but pgr_withPointsDD still has the exact same problem it has on main: unchanged code, wrong message, and it wrongly rejects distance = 0.

• pgr_primDD / pgr_kruskalDD / pgr_drivingDistance already throw a standardized error for negative distance.
• pgr_withPointsDD still throws a different, non-standard message, and still rejects distance = 0, which every other catchment function accepts.
• Minor secondary inconsistency: pgr_primDD / pgr_kruskalDD use the hint Must be non negative, while pgr_drivingDistance uses Must be positive same situation (negative rejected, zero accepted) described with two different hints.

All four functions below use the same minimal inline graph, so each block can be run standalone, in order, to reproduce the behaviours.

Reproduction

-- pgr_primDD: already standardized
SELECT * FROM pgr_primDD(
    'SELECT * FROM (VALUES (100,1,2,1,1),(101,2,3,1,1),(102,3,4,1,1))
     AS e(id,source,target,cost,reverse_cost)',
    1, -3.5
);
-- ERROR:  Negative value found on 'distance'
-- Must be non negative

-- pgr_kruskalDD: already standardized
SELECT * FROM pgr_kruskalDD(
    'SELECT * FROM (VALUES (100,1,2,1,1),(101,2,3,1,1),(102,3,4,1,1))
     AS e(id,source,target,cost,reverse_cost)',
    1, -3.5
);
-- ERROR:  Negative value found on 'distance'
-- Must be non negative

-- pgr_drivingDistance: already standardized
SELECT * FROM pgr_drivingDistance(
    'SELECT * FROM (VALUES (100,1,2,1,1),(101,2,3,1,1),(102,3,4,1,1))
     AS e(id,source,target,cost,reverse_cost)',
    1, -3.5
);
-- ERROR:  Negative value found on 'distance'
-- Must be positive

-- pgr_withPointsDD: NOT standardized, different message, unchanged from main
SELECT * FROM pgr_withPointsDD(
    'SELECT * FROM (VALUES (100,1,2,1,1),(101,2,3,1,1),(102,3,4,1,1))
     AS e(id,source,target,cost,reverse_cost)',
    'SELECT * FROM (VALUES (1,100,0.5,''b'')) AS p(pid,edge_id,fraction,side)',
    1, -3.5, 'b'
);
-- ERROR:  Invalid value of 'distance'
-- Valid values are greater than 0

-- pgr_withPointsDD: also wrongly rejects distance = 0
SELECT * FROM pgr_withPointsDD(
    'SELECT * FROM (VALUES (100,1,2,1,1),(101,2,3,1,1),(102,3,4,1,1))
     AS e(id,source,target,cost,reverse_cost)',
    'SELECT * FROM (VALUES (1,100,0.5,''b'')) AS p(pid,edge_id,fraction,side)',
    1, 0, 'b'
);
-- ERROR:  Invalid value of 'distance'
-- Valid values are greater than 0

Summary

Function	distance < 0	distance = 0
pgr_primDD	throws Negative value found on 'distance' / Must be non negative	accepted
pgr_kruskalDD	throws Negative value found on 'distance' / Must be non negative	accepted
pgr_drivingDistance	throws Negative value found on 'distance' / Must be positive	accepted
pgr_withPointsDD	throws Invalid value of 'distance' / Valid values are greater than 0	rejected (should be accepted)

Expected

• pgr_withPointsDD should be brought in line with the other three: throw
  Negative value found on 'distance' for distance < 0, and accept distance = 0.
• The hint text should also be made consistent across all four functions (currently a
  mix of Must be positive and Must be non negative).

[cvvergara]

See #3091
The same applies.