You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of data types which have been removed via type erasure when using the .column syntax for ingest with the C++ API. Many of these should be supported according to Quest's official API but are not possible for use with this library: https://questdb.com/docs/reference/sql/datatypes/
A good example is Quest's byte data type. Trying to use any C++ equivalent, eg std::byte, int8_t, char, unsigned char all produce an error saying these functions have been deleted for those data types in the template.
It also doesn't appear possible to use Symbols.
Are these expected deficiencies or is there a reason they were excluded? I can probably put together a PR if there's an intent to support these in the future.
The text was updated successfully, but these errors were encountered:
The ILP protocol itself does not support such types. Across the clients, the API supports what the protocol allows.
To ingest into columns of other types, we implicitly cast the type behind the scenes.
We are in the first stages of swapping to a new bespoke binary protocol, which will eventually support all QuestDB features. The first step is for the new ARRAY type, with additional types to follow.
Once the types are natively supported, then the API can reflect this.
There are a number of data types which have been removed via type erasure when using the
.column
syntax for ingest with the C++ API. Many of these should be supported according to Quest's official API but are not possible for use with this library: https://questdb.com/docs/reference/sql/datatypes/A good example is Quest's byte data type. Trying to use any C++ equivalent, eg
std::byte, int8_t, char, unsigned char
all produce an error saying these functions have been deleted for those data types in the template.It also doesn't appear possible to use Symbols.
Are these expected deficiencies or is there a reason they were excluded? I can probably put together a PR if there's an intent to support these in the future.
The text was updated successfully, but these errors were encountered: