pgr_withPoints family silently returns 0 rows on PG 18 / pgRouting 4.0.1 Windows MSVC build (canonical example fails)

[b-j-karl]

Summary

On a Windows MSVC build of PostgreSQL 18.3 + PostGIS 3.6.2 + pgRouting 4.0.1 (installed via the EnterpriseDB Stack Builder bundle), every function in the pgr_withPoints family e.g., pgr_withPoints, pgr_withPointsCost, pgr_withPointsKSP, silently returns 0 rows even on the canonical docs example. [DEBUG] No paths found is the only notice. pgr_dijkstra works correctly on the same edges_sql, so the algorithm dispatch and the SPI layer are fine; the failure is specific to the _pgr_withPoints_v4 C SRF or the points-graph augmentation it performs.

Versions

PostgreSQL 18.3 on x86_64-windows, compiled by msvc-19.44.35223, 64-bit
postgis     3.6.2
pgrouting   4.0.1

Installed via the postgis.net Windows bundle / EDB Stack Builder for PG 18 (the only Windows MSVC build of pgRouting 4.0.1 in widespread distribution as far as I can tell).

Reproduction

The canonical "two edges, two virtual points" example:

SET client_min_messages = 'DEBUG1';

-- Sanity: pgr_dijkstra works.
SELECT seq, node, edge, cost FROM pgr_dijkstra(
    $$
        SELECT 1::bigint AS id, 1::bigint AS source, 2::bigint AS target,
               1.0::float AS cost, 1.0::float AS reverse_cost
        UNION ALL
        SELECT 2::bigint, 2::bigint, 3::bigint, 1.0::float, 1.0::float
    $$,
    1, 3, directed => true
);
-- Output:
--  seq | node | edge | cost
-- -----+------+------+------
--    1 |    1 |    1 |    1
--    2 |    2 |    2 |    1
--    3 |    3 |   -1 |    0

-- pgr_withPoints on the same graph: 0 rows.
SELECT seq, path_seq, start_vid, end_vid, node, edge, cost, agg_cost
FROM pgr_withPoints(
    $$
        SELECT 1::bigint AS id, 1::bigint AS source, 2::bigint AS target,
               1.0::float AS cost, 1.0::float AS reverse_cost
        UNION ALL
        SELECT 2::bigint, 2::bigint, 3::bigint, 1.0::float, 1.0::float
    $$,
    $$
        SELECT (-1)::bigint AS pid, 1::bigint AS edge_id, 0.5::float AS fraction
        UNION ALL SELECT (-2)::bigint, 2::bigint, 0.5::float
    $$,
    (-1)::bigint, (-2)::bigint,
    directed => true
);
-- DEBUG: No paths found
-- (0 rows)

Expected: 4 rows describing the path virtual(-1) → vertex 2 → virtual(-2).
Actual: 0 rows, single [DEBUG] No paths found notice, no error, no warning.

What I've ruled out

• It's not the call-site SQL. The above is the canonical pattern from the docs.
• It's not signature/overload resolution. The wrapper resolves to pgr_withpoints(text, text, bigint, bigint, directed boolean, details boolean). \df pgr_withpoints shows all 9 expected overloads.
• It's not a NULL slipping through STRICT. Tried both with and without directed/details named args, both 'b'/'r'/'l' for driving_side (positional 5-arg overload), positive and negative pids, real-vertex-to-virtual and virtual-to-real, two edges or one. Every variation returns 0 rows with the same [DEBUG] No paths found.
• It's not stale extension binary. DROP EXTENSION pgrouting CASCADE; CREATE EXTENSION pgrouting; then re-run → still 0 rows.
• It's not the points_sql being empty. Inner SELECT pid, edge_id, fraction returns the expected 2 rows when run standalone.
• It's not the SPI dispatch layer. pgr_dijkstra (src/dijkstra/) works on the exact same edges_sql, returning the expected 3 rows. So pgr_SPI_connect / SPI_execute / TupleDesc all function under PG 18 on this build.

This isolates the failure to the _pgr_withPoints_v4 C SRF or the Pg_points_graph augmentation step it performs (src/withPoints/withPoints_driver.cpp or src/cpp_common/Pg_points_graph.cpp). The "No paths found" debug message suggests the augmented graph is being built, Dijkstra runs, and finds nothing i.e. the virtual nodes are inserted but disconnected from the rest of the augmented graph. That's consistent with a memory / struct-alignment issue in the augmentation that surfaces only on the MSVC build, not on Linux.

Linux PG 18 + 4.0.1 works (per CI)

.github/workflows/ubuntu.yml at v4.0.1 runs the withPoints regression suite (docqueries/withPoints/withPoints.pg) against PG 18, so this is not an algorithm bug — it's specific to the Windows MSVC binary.

Severity / urgency

Not urgent for me, I worked around it by reimplementing pgr_withPoints semantics in my application (snap to nearest edge → many-to-many pgr_dijkstra over the four endpoint combinations -> score by partial_src + dijkstra + partial_tgt -> clip with ST_LineSubstring). Filing because:

1. The next person who runs PG 18 + EDB Stack Builder + pgRouting 4.0.1 on Windows hits this the same way and would have to debug it from scratch — there's no matching open issue I could find.
2. CI claims PG 18 support, so the Windows MSVC build silently regressing the entire withPoints family is worth knowing about regardless of platform priorities.
3. The reproduction is fully self-contained (no real graph data needed), so triage cost is low.

If the right place for this is the postgis.net bundle / EnterpriseDB packagers rather than pgRouting itself, please redirect.

What might help isolate further

Happy to run any further diagnostic you'd like e.g. building from source on the same Windows machine, comparing against a Linux build of the same tag, or capturing additional log levels. Just point me at what you'd find useful.