Skip to content

State a literal a C wrapper passes as a value operand of its composition - #181

Merged
estebanzimanyi merged 1 commit into
MobilityDB:masterfrom
estebanzimanyi:catalog/wrapper-literal-operands
Oct 9, 2026
Merged

estebanzimanyi merged 1 commit into
MobilityDB:masterfrom
estebanzimanyi:catalog/wrapper-literal-operands

Conversation

@estebanzimanyi

Copy link
Copy Markdown
Member

A C wrapper that casts an argument before its call and passes a C literal for a parameter the SQL
signature does not carry states that parameter as a value operand: eDwithin(tpose, geometry,
float), whose wrapper Edwithin_tpose_geo casts with tpoint = tpose_to_tpoint(temp) and calls
edwithin_tgeo_geo(tpoint, gs, dist, true), is the composition of operand 0 through
tpose_to_tpoint, operands 1 and 2 as they are, and the value true for spheroid, the operand form
A7 states for a value a SQL body binds. A literal is true, false or a number.

Witness: on MobilityDB master 2334c439ab edwithin_tgeo_geo, edwithin_geo_tgeo and
edwithin_tgeo_tgeo take a spheroid flag the SQL eDwithin over tpose does not carry, so a tpose
wrapper calling them passes true; master's attach_wrapper_compositions finds no SQL argument for
the literal, leaves the three signatures eDwithin(geometry, tpose, float), eDwithin(tpose,
geometry, float) and eDwithin(tpose, tpose, float) among the sqlSignatures of those functions,
and a binding passes them a tpose they refuse.

Measured: over a MobilityDB tree on master 2334c439ab whose six tpose wrappers call the public
tgeo functions, run.py states 6 tpose compositions, the three eDwithin with the value true for
spheroid, and no tpose signature on the tgeo functions; master's parser over the same tree states
3 and leaves the three eDwithin signatures on the tgeo functions. Over MobilityDB master
2334c439ab every key of the catalog equals that of master's parser. The suite passes the new test
tests/test_compositions.py test_a_literal_argument_is_a_value_operand, which fails with master's
parser, with 484 passed and 25 skipped against 483 and 25 with master's parser, the same three
struct and family tests failing in both over a catalog generated from the source headers.

Why: a binding reaches a relationship of a derived type through the cast and the function of its
cast target with every parameter that function reads bound, as PostgreSQL's wrapper binds it.

A C wrapper that casts an argument before its call and passes a C literal for a parameter the SQL
signature does not carry states that parameter as a value operand: eDwithin(tpose, geometry,
float), whose wrapper Edwithin_tpose_geo casts with tpoint = tpose_to_tpoint(temp) and calls
edwithin_tgeo_geo(tpoint, gs, dist, true), is the composition of operand 0 through
tpose_to_tpoint, operands 1 and 2 as they are, and the value true for spheroid, the operand form
A7 states for a value a SQL body binds. A literal is true, false or a number.

Witness: on MobilityDB master 2334c439ab edwithin_tgeo_geo, edwithin_geo_tgeo and
edwithin_tgeo_tgeo take a spheroid flag the SQL eDwithin over tpose does not carry, so a tpose
wrapper calling them passes true; master's attach_wrapper_compositions finds no SQL argument for
the literal, leaves the three signatures eDwithin(geometry, tpose, float), eDwithin(tpose,
geometry, float) and eDwithin(tpose, tpose, float) among the sqlSignatures of those functions,
and a binding passes them a tpose they refuse.

Measured: over a MobilityDB tree on master 2334c439ab whose six tpose wrappers call the public
tgeo functions, run.py states 6 tpose compositions, the three eDwithin with the value true for
spheroid, and no tpose signature on the tgeo functions; master's parser over the same tree states
3 and leaves the three eDwithin signatures on the tgeo functions. Over MobilityDB master
2334c439ab every key of the catalog equals that of master's parser. The suite passes the new test
tests/test_compositions.py test_a_literal_argument_is_a_value_operand, which fails with master's
parser, with 484 passed and 25 skipped against 483 and 25 with master's parser, the same three
struct and family tests failing in both over a catalog generated from the source headers.

Why: a binding reaches a relationship of a derived type through the cast and the function of its
cast target with every parameter that function reads bound, as PostgreSQL's wrapper binds it.
@estebanzimanyi
estebanzimanyi merged commit c6f423d into MobilityDB:master Oct 9, 2026
3 checks passed
@estebanzimanyi
estebanzimanyi deleted the catalog/wrapper-literal-operands branch October 9, 2026 07:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant