Execute a SQL statement (query, DML, or DDL).See SQL Support for the complete set of supported SQL
commands.When a caller wants all the results from a large query (e.g., more than
max_get_records_size records), they
can make multiple calls to this endpoint using the input parameter offset and
input parameter limit parameters to page through the results. Normally, this
will execute the input parameter statement query each time. To avoid
re-executing the query each time and to keep the results in the same order, the
caller should specify a paging_table name to hold the results of the query
between calls and specify the paging_table on subsequent calls. When this is
done, the caller should clear the paging table and any other tables in the
result_table_list (both returned in the response) when they are done paging
through the results. Output parameter paging_table (and result_table_list)
will be empty if no paging table was created (e.g., when all the query results
were returned in the first call).
A positive integer indicating the number of initial results to skip (this can be useful for paging through the results).The default value is 0. The minimum allowed value is 0. The maximum allowed value is MAX_INT.
A positive integer indicating the maximum number of results to be returned, or END_OF_SET (-9999) to indicate that the maximum number of results allowed by the server should be returned. The number of records returned will never exceed the server’s own limit, defined by the max_get_records_size parameter in the server configuration. Use output parameter has_more_records to see if more records exist in the result to be fetched, and input parameter offset and input parameter limit to request subsequent pages of results.The default value is -9999.
An array of binary-encoded data for the records to be binded to the SQL query. Or use query_parameters to pass the data in JSON format.The default value is an empty array ( [] ).
If true, enables the use of distributed joins in servicing the given query. Any query requiring a distributed join will succeed, though hints can be used in the query to change the distribution of the source data to allow the query to succeed.The default value is false.The supported values are:
If true, enables the use of distributed operations in servicing the given query. Any query requiring a distributed join will succeed, though hints can be used in the query to change the distribution of the source data to allow the query to succeed.The default value is false.The supported values are:
Specifies the record collision error-suppression policy for inserting into or updating a table with a primary key, only used when primary key record collisions are rejected (update_on_existing_pk is false). If set to true, any record insert/update that is rejected for resulting in a primary key collision with an existing table record will be ignored with no error generated. If false, the rejection of any insert/update for resulting in a primary key collision will cause an error to be reported. If the specified table does not have a primary key or if update_on_existing_pk is true, then this option has no effect.The default value is false.
true: Ignore inserts/updates that result in primary key collisions with existing records.
false: Treat as errors any inserts/updates that result in primary key collisions with existing records.
When specified (or paging_table_ttl is set), the system will create a paging table to hold the results of the query, when the output has more records than are in the response (i.e., when output parameter has_more_records is true). If the specified paging table exists, the records from the paging table are returned without re-evaluating the query. It is the caller’s responsibility to clear the output parameter paging_table and other tables in the result_table_list (both returned in the response) when they are done with this query.
Sets the TTL of the paging table. -1 indicates no timeout. Setting this option will cause a paging table to be generated when needed. The output parameter paging_table and other tables in the result_table_list (both returned in the response) will be automatically cleared after the TTL expires, if set to a positive number. However, it is still recommended that the caller clear these tables when they are done with this query.
If true, compiles a query into an execution plan and saves it in query cache. Query execution is not performed and an empty response will be returned to user.The default value is false.The supported values are:
If true, then columns that were dict encoded in the source table will be dict encoded in the projection table.The default value is true.The supported values are:
Query parameters in JSON array or arrays (for inserting multiple rows). This can be used instead of input parameter data and input parameter request_schema_str.
Specifies the record collision policy for inserting into or updating a table with a primary key. If set to true, any existing table record with primary key values that match those of a record being inserted or updated will be replaced by that record. If set to false, any such primary key collision will result in the insert/update being rejected and the error handled as determined by ignore_existing_pk. If the specified table does not have a primary key, then this option has no effect.The default value is false.
true: Replace the collided-into record with the record inserted or updated when a new/modified record causes a primary key collision with an existing record.
false: Reject the insert or update when it results in a primary key collision with an existing record.
When changing a column using alter table, validate the change before applying it. If true, then validate all values. A value too large (or too long) for the new type will prevent any change. If false, then when a value is too large or long, it will be truncated.The default value is true.The supported values are:
The Kinetica server embeds the endpoint response inside a standard response structure which contains status information and the actual response to the query. Here is a description of the various fields of the wrapper:
Name of the table that has the result records of the query. Valid, when output parameter has_more_records is true. The caller should clear this and all tables in result_table_list when they are done querying.
List of tables, comma-separated, in addition to the output parameter paging_table, created as result of the query. These should be cleared by the caller when they are done querying.
