[estebanzimanyi]

sql_signature reads RETURNS TABLE (...) as PostgreSQL defines it, a set of rows whose columns are its OUT arguments: a set of record whose columns are the table's, or a set of the type of its one column. meta/sql-columns.json states the field of the returned structure feeding each column where a column's name or a field no column reads leaves it to the statement: the rows of pixelAsPoints read the geom, the value, the x and the y of each Pixel, and those of geoPoseFrames each field of a GeoPoseFrame by the column of its name.

A row whose columns nothing feeds still stops the catalog, but for a signature passing a SQL array where the function takes one element of it (_loops_over_an_array): that signature is the wrapper's loop of calls, not a projection of the function, and attach_row_sources gives it up as attach_claims_fit gives up an unfit shared signature. dumpValues(raster, integer[], boolean) calls raster_dump_values once per band of its array, each row's nband a band of the argument, and the function keeps its one-band signature dumpValues(raster, integer, boolean).

Measured over MobilityDB master 1a7a1a0e11: the catalog differs from master's in geopose_frames and raster_pixel_as_points, whose signatures state their rows, and in raster_dump_values, which keeps its one-band signature; _loops_over_an_array holds for that one signature of the catalog. Over that catalog the JVM generators of JMEOS main answer pixelAsPoints on the typed Spark and Flink surfaces, 1305 SQL functions and 9373 overloads where master's catalog gives 1304 and 9370, refuse geoPoseFrames as setret:column/return:text, and the Spark gaps ledger is unchanged; MobilityDuck main's generator writes the same files. tests/test_sqlfn_rows.py reads a RETURNS TABLE of several columns and of one, gives up the unfed row of a signature looping over an array, and stops on the unfed row of a signature that does not; the suite passes, 593 tests and none skipped.