Skip to content

Read the endian of a WKB writer from its text on the typed SQL surfaces - #160

Merged
estebanzimanyi merged 1 commit into
MobilityDB:mainfrom
estebanzimanyi:codegen/endian-text
Oct 5, 2026
Merged

estebanzimanyi merged 1 commit into
MobilityDB:mainfrom
estebanzimanyi:codegen/endian-text

Conversation

@estebanzimanyi

Copy link
Copy Markdown
Member

The typed Spark and Flink SQL surfaces read a uint8_t argument from its SQL text through
wkb_variant_from_endian, the one public MEOS function reading a uint8_t from a string, as they
read an enum from its name through its own reader. SqlModel registers a reader for each enum and
for each by-value C type that no SQL scalar carries and that exactly one public function reads
from a string; the C types a SQL scalar carries (the elements SQL_ARRAY_SCALAR names, bool,
int32_t and uint64_t) stay values. Every public uint8_t parameter of the catalog is the variant a
WKB writer takes, so asBinary, asHexWKB, asEWKB and asHexEWKB reach every type: the endian
'NDR', 'XDR' or '' becomes the variant, and the E names call the _as_ewkb and
_as_hexewkb writers that add WKB_EXTENDED to it.

Witness: over the catalog and libmeos of MobilityDB 72d6566b01 and MEOS-API 0438baabc6, main
refuses 186 signatures as arg:text, the endian argument of asBinary, asHexWKB, asEWKB and
asHexEWKB.

Measured over the same pair: both engines register 1134 SQL functions and 8228 overloads where
main registers 1132 and 7856, the 372 overloads being 186 signatures (asBinary 61, asHexWKB 61,
asEWKB 32, asHexEWKB 32) with and without their defaulted endian, and no signature is refused as
arg:text; asEWKB and asHexEWKB of nsegment call nsegment_as_ewkb and nsegment_as_hexewkb as those
of every other type call their own E writer; the reader table differs from main in uint8_t
alone, and of the generated sources only the four binary functions and the registries differ. Through MobilitySpark's typed surface,
asHexWKB(stbox 'SRID=3812;STBOX X((1,1),(2,2))', 'NDR') answers
0101000000000000F03F0000000000000040000000000000F03F0000000000000040, its 'XDR' form the
same bytes big-endian, asEWKB and asHexEWKB
0141E40E0000000000000000F03F0000000000000040000000000000F03F0000000000000040, which
stboxFromHexEWKB reads back as SRID=3812;STBOX X((1,1),(2,2)), and the EWKB of a tgeompoint
carries its SRID 4326 where its WKB carries none. The build and the 1906 tests pass with no
warning, and MobilitySpark's 34 tests pass with this generator.

Why: the endian is the one SQL text of a WKB writer, and MEOS states the function that reads
it, so every binary form of every type reaches both engines through the public API alone.

The typed Spark and Flink SQL surfaces read a uint8_t argument from its SQL text through
wkb_variant_from_endian, the one public MEOS function reading a uint8_t from a string, as they
read an enum from its name through its own reader. SqlModel registers a reader for each enum and
for each by-value C type that no SQL scalar carries and that exactly one public function reads
from a string; the C types a SQL scalar carries (the elements SQL_ARRAY_SCALAR names, bool,
int32_t and uint64_t) stay values. Every public uint8_t parameter of the catalog is the variant a
WKB writer takes, so asBinary, asHexWKB, asEWKB and asHexEWKB reach every type: the endian
'NDR', 'XDR' or '' becomes the variant, and the E names call the <type>_as_ewkb and
<type>_as_hexewkb writers that add WKB_EXTENDED to it.

Witness: over the catalog and libmeos of MobilityDB 72d6566b01 and MEOS-API 0438baabc6, main
refuses 186 signatures as arg:text, the endian argument of asBinary, asHexWKB, asEWKB and
asHexEWKB.

Measured over the same pair: both engines register 1134 SQL functions and 8228 overloads where
main registers 1132 and 7856, the 372 overloads being 186 signatures (asBinary 61, asHexWKB 61,
asEWKB 32, asHexEWKB 32) with and without their defaulted endian, and no signature is refused as
arg:text; asEWKB and asHexEWKB of nsegment call nsegment_as_ewkb and nsegment_as_hexewkb as those
of every other type call their own E writer; the reader table differs from main in uint8_t
alone, and of the generated sources only the four binary functions and the registries differ. Through MobilitySpark's typed surface,
asHexWKB(stbox 'SRID=3812;STBOX X((1,1),(2,2))', 'NDR') answers
0101000000000000F03F0000000000000040000000000000F03F0000000000000040, its 'XDR' form the
same bytes big-endian, asEWKB and asHexEWKB
0141E40E0000000000000000F03F0000000000000040000000000000F03F0000000000000040, which
stboxFromHexEWKB reads back as SRID=3812;STBOX X((1,1),(2,2)), and the EWKB of a tgeompoint
carries its SRID 4326 where its WKB carries none. The build and the 1906 tests pass with no
warning, and MobilitySpark's 34 tests pass with this generator.

Why: the endian is the one SQL text of a WKB writer, and MEOS states the function that reads
it, so every binary form of every type reaches both engines through the public API alone.
@estebanzimanyi
estebanzimanyi merged commit bade992 into MobilityDB:main Oct 5, 2026
2 checks passed
@estebanzimanyi
estebanzimanyi deleted the codegen/endian-text branch October 5, 2026 22:20
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