Rather than bloat the main FFI objects with more and more optional fields to support each new feature we want to add over time (which creates large unwieldy objects), we want to have an "extensions" mechanisms that will allow for future development without constantly expanding these objects.
Either in the CommonConfig objects or Leaf query config FFI objects, we will create an extensions array. This will be an array of a tagged union type, similar to the FFIRowKeyValue tagged union type. The enum will be an expandable set of supported extensions. SQL string for a query will be the first (and currently only) type. Each extension type will be validated in Rust, since we anticipate some being singleton per query and some in the future maybe n-ary. For example we will only support one SQL statement per query, so this will be singleton.
Rather than bloat the main FFI objects with more and more optional fields to support each new feature we want to add over time (which creates large unwieldy objects), we want to have an "extensions" mechanisms that will allow for future development without constantly expanding these objects.
Either in the CommonConfig objects or Leaf query config FFI objects, we will create an extensions array. This will be an array of a tagged union type, similar to the
FFIRowKeyValuetagged union type. The enum will be an expandable set of supported extensions. SQL string for a query will be the first (and currently only) type. Each extension type will be validated in Rust, since we anticipate some being singleton per query and some in the future maybe n-ary. For example we will only support one SQL statement per query, so this will be singleton.