Closed vpetrovykh closed 2 years ago
I think tsquery-, and tsvector-like types should be discussed in the spec even if rejected.
The idea is that query (and/or content) could be parsed on the client in any client-specific way is still very solid. I think the biggest issue here is that to make it efficient for postgres, the representation of that has to be postgres-specific, right?
I think the biggest issue here is that to make it efficient for postgres, the representation of that has to be postgres-specific, right?
We can make them using JSON in runtime and casting to postgres-specific underlying types when needed.
I think the biggest issue here is that to make it efficient for postgres, the representation of that has to be postgres-specific, right?
We can make them using JSON in runtime and casting to postgres-specific underlying types when needed.
The problem is that Elasticsearch's json is something like this:
{
"query": {
"query_string": {
"query": "(new york city) OR (big apple)",
"default_field": "content"
}
}
}
But in postgres it should be like this, I think:
(new:A & york:A & city:A) OR (big:A & apple:A)
I.e. its not just get the query from inside the JSON, but also operators in text are different and how fields are matched is different, etc. And this is just the simplest query for elastic.
A draft proposal of the full-text search funcitonality for EdgeDB.