docs: st_collect_agg and st_makeline are missing their geography kernels in the SQL reference

[jiayuasu]

Description

docs/reference/sql/st_collect_agg.qmd and docs/reference/sql/st_makeline.qmd declare only a geometry kernel:

# st_collect_agg.qmd
kernels:
  - returns: geometry
    args: [geometry]

# st_makeline.qmd
kernels:
  - returns: geometry
    args: [geometry, geometry]

But 0.4.0 accepts geography for both, and returns geography:

import json, sedonadb
sd = sedonadb.connect()
opts = json.dumps({"geom_type": "Point", "bounds": [0, 0, 10, 10], "seed": 11})
sd.sql(f"SELECT id, ST_GeogFromWKB(ST_AsBinary(geometry)) AS geog, "
       f"ST_GeomFromWKB(ST_AsBinary(geometry)) AS geom "
       f"FROM sd_random_geometry('{opts}') LIMIT 50").to_view("t", overwrite=True)
sd.sql("SELECT id, geog, geom FROM t").to_view("u", overwrite=True)

sd.sql("SELECT ST_GeometryType(ST_Collect_Agg(geog)) FROM t").to_pandas()
# -> ST_MultiPoint

sd.sql("SELECT ST_Area(ST_ConvexHull(ST_Collect_Agg(geog))) FROM t").to_pandas()
# -> 970542623930.96      (m^2 -- the spherical path)

sd.sql("""SELECT ST_Length(ST_MakeLine(a.geog, b.geog))
          FROM t a, u b WHERE a.id = 1 AND b.id = 2""").to_pandas()
# -> 865168.17            (metres)

sd.sql("""SELECT ST_Length(ST_MakeLine(a.geom, b.geom))
          FROM t a, u b WHERE a.id = 1 AND b.id = 2""").to_pandas()
# -> 7.87                 (degrees -- same two points, geometry overload)

865 168 m vs 7.87 degrees for the same pair of points confirms these are really going through the geography path, not silently downcasting to geometry.

Suggested fix

Add the geography overloads to the kernels: blocks:

# st_collect_agg.qmd
kernels:
  - returns: geometry
    args: [geometry]
  - returns: geography
    args: [geography]

# st_makeline.qmd
kernels:
  - returns: geometry
    args: [geometry, geometry]
  - returns: geography
    args: [geography, geography]

It would also be worth auditing the other .qmd kernel lists against the registry, in case more geography overloads are undocumented — a generated check would keep them honest.

Why it matters

The kernels: metadata is the natural place to look when working out what the geography type can do. Taking it at face value, I concluded that SpatialBench's Q5 (ST_Collect_Agg + ST_ConvexHull) and Q7 (ST_MakeLine + ST_Length) had no geography formulation, and shipped them as documented-but-unimplemented. Both in fact work on 0.4.0, so ten of the twelve SpatialBench queries have a working geography version rather than eight.

Environment

• sedonadb 0.4.0 (PyPI wheel), Python 3.13, macOS arm64
• sedonadb.__features__ == ['s2geography']