elastic / elasticsearch

Free and Open Source, Distributed, RESTful Search Engine
https://www.elastic.co/products/elasticsearch
Other
1.06k stars 24.83k forks source link

ESQL: Functions! #98545

Open nik9000 opened 1 year ago

nik9000 commented 1 year ago

Description

Description

This is a list of "shovel ready" functions. It's functions we are fairly sure we want and we should be able to start working on them now. This list is not sorted at all, partly because making any one of these functions shouldn't be a huge effort so the cost of having a sorted list is comparatively high.

This list is not sacred. If you need a function to do something, stick it on the list. Maybe even build it yourself, it's fun!

NULL

IP

Math

String

Date

Encode/Decode

Secure Hashing

Aggregate (STATS ... BY)

elasticsearchmachine commented 1 year ago

Pinging @elastic/es-ql (Team:QL)

elasticsearchmachine commented 1 year ago

Pinging @elastic/elasticsearch-esql (:Query Languages/ES|QL)

nik9000 commented 1 year ago

I wrote up a guide to making new functions about six months ago that's gone stale. I'll try and build another guide for it on Monday.

dreamquster commented 1 year ago

@nik9000 I had wrote partial logic of 'left' function. Now I wonder how do i write the manual document about it. Furthermore, the variable named 'length' should be optional or mandatory This is my pull request: https://github.com/elastic/elasticsearch/pull/98660

nik9000 commented 1 year ago

Here are some instructions for adding functions.

elasticsearchmachine commented 10 months ago

Pinging @elastic/es-analytics-geo (Team:Analytics)

elasticsearchmachine commented 9 months ago

Pinging @elastic/es-analytical-engine (Team:Analytics)

ioanatia commented 4 months ago

With DATE_EXTRACT being available I wonder if it still make sense to support many of the functions listed under the DATE section here.

nik9000 commented 4 months ago

With DATE_EXTRACT being available I wonder if it still make sense to support many of the functions listed under the DATE section here.

Yeah, I think we probably can just zap them. At most they can be aliases to DATE_EXTRACT. But they aren't nearly as important.

@costin, what do you think of just crossing them out of hte list?

drewdaemon commented 3 weeks ago

Does TYPEOF make sense on this list (comparable)? Union types can come up ~when using CASE (e.g. var0 = CASE(boolField, 1, "foo")). Also,~ potentially when using multiple indices with different types.

nik9000 commented 2 weeks ago

I think TYPEOF makes a lot of sense with union types. I'd probably want to develop it with some union type work that uses it. And have a look to see if what we need lines up exactly with the sqllite function. If, say, we decide we should have different handling for null somehow we might not want to name it this. Not that we'd make that decision lightly - conforming to what folks are used to is quite an advantage. But I imagine a world where TYPEOF is always evaluated at query planning time on the data node.