Repository navigation
Read the endian of a WKB writer from its text on the typed SQL surfaces - #160
Merged
estebanzimanyi merged 1 commit intoOct 5, 2026
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.