* SQL: fix name of Arithmetic functions
Remove id from name of Arithmetic function and improve name of Neg
Original commit: elastic/x-pack-elasticsearch@4f3e8d6a2d
There were a number of leftover unnecessary elements in the module
build.gradle files that were holdovers from copying the original plugin
build.gradle. This commit removes these elements.
Original commit: elastic/x-pack-elasticsearch@08babbd520
The old home made sense before x-pack was split. The new home lines up
with where security keeps its scripts.
The jar file wasn't being included any more so this re-adds that.
Original commit: elastic/x-pack-elasticsearch@d3ec941397
This allows any datetime function to be present in `EXTRACT` which feels
more consistent. `EXTRACT(FOO FROM bar)` is now just sugar for
`FOO(bar)`. This is *much* simpler to explain in the documentation then
"these 10 fields are supported by extract and they are the same as this
subset of the datetime functions."
The implementation of this is a little simpler then the old way. Instead
of resolving the function in the parser we create an
`UnresolvedFunction` that looks *almost* just like what we'd create for
a single argument function and resolve the function in the `Analyzer`.
This feels like a net positive as it allows us to group `EXTRACT`
resolution failures with other function resolution failures.
This also creates `UnresolvedFunctionTests` and
`UnresolvedAttributeTests`. I had to create `UnresolvedFunctionTests`
because `UnreolvedFunction` now has three boolean parameters which is
incompatible with the generic `NodeSubclassTests`'s requirement that all
ctor parameters be unique. I created `UnresolvedAttributeTests` because
I didn't want `UnresolvedFunctionTests` to call `NodeSubclassTests` and
figured that we'd want `UnresolvedAttributeTest` eventually and now felt
like as good a time as any.
Added a
Original commit: elastic/x-pack-elasticsearch@358aada308
Consolidates handling of JDBC types conversion into a single file that should simplify maintaining consistency between type handling. Also separates the types that are handled as part of Elasticsearch output and types that are handled as user-supplied parameters.
relates elastic/x-pack-elasticsearch#3556
Original commit: elastic/x-pack-elasticsearch@d251fce66b
Introduce system commands as alternative to meta HTTP endpoints
Pass in cluster name
Use 'BASE TABLE' instead of 'INDEX' when describing a table to stick
with the SQL terminology
Original commit: elastic/x-pack-elasticsearch@600312b8f7
In order to more easily integrate xpack once it moves into the
elasticsearch repo, references to the existing x-pack-elasticsearch need
to be reduced. This commit introduces a few helper "methods" available
to any project within xpack (through gradle project extension
properties, as closures). All refeerences to project paths now use these
helper methods, except for those pertaining to bwc, which will be
handled in a followup.
Original commit: elastic/x-pack-elasticsearch@850668744c
This commit moves the exception classes that SQL uses to follow the
Elasticsearch convention. In the places where varargs were used, the
`LoggerMessageFormat` (`{}`) standard is used instead.
In also removes on Exception - `ExecutionException` since it seemed to not ever
be beefed up, it can be re-added later if needed.
This removes the varargs version of `ClientException` to push the formatting
back on the caller, since `ClientException` cannot depend on Elasticsearch for
formatting the arguments.
There were also a couple of places where we incorrectly passed the Throwable
cause as a var-arg and were unintentionally swallowing it since `String.format`
discards unused arguments.
Relates to elastic/x-pack-elasticsearch#2880
Original commit: elastic/x-pack-elasticsearch@5f5d580e57
Fixes an issue in the test where the class can be constructed but fails to
replace its children due to validation of the number of elements in the list.
Original commit: elastic/x-pack-elasticsearch@3199318d9c
Adds documentation for all of the date time functions using the new
cli-like format extracted from the csv spec. In the process of doing
this I noticed that the `WEEK` function isn't exposed as a function.
This exposes it for consistency.
Relates to elastic/x-pack-elasticsearch#2898
Original commit: elastic/x-pack-elasticsearch@0459b24cb9
I went to write some docs for datetime functions that look like:
```
SELECT YEAR(CAST('2018-01-19T10:23:27Z' AS TIMESTAMP)) as year;
year
2018
```
because I figured they'd be pretty easy to read because they didn't
require any knowledge of a data set. But it turns out that constant
folding doesn't work properly for date time functions because they don't
actually apply the extraction.
Original commit: elastic/x-pack-elasticsearch@aa9c66b2c7
Since we don't do any serialization of Cursor classes from the Transport
side (it is treated entirely as a string), we don't actually need to tell anyone
about SQL's writeables
Original commit: elastic/x-pack-elasticsearch@ad2c10e327
This is the next step in removing the top level sql directory.
I named the directory `sql-cli` instead of `cli` because that puts it at
the maven coordinates `org.elasticsearch.plugin:sql-cli` instead of
`org.elasticsearch.plugin:cli`.
Relates to elastic/x-pack-elasticsearch#3363
Original commit: elastic/x-pack-elasticsearch@d41a57a136
This moves SQL's server project into `plugin:sql` without modifying how the integration is performed. I know that it is not correct with regards to the x-pack modularization but I think it is a good first step.
Original commit: elastic/x-pack-elasticsearch@2f40d02e4d
