edgedb / rfcs

RFCs for major changes to EdgeDB
Apache License 2.0
35 stars 5 forks source link

RFC 1015: Full text search #64

Closed vpetrovykh closed 2 years ago

vpetrovykh commented 2 years ago

A draft proposal of the full-text search funcitonality for EdgeDB.

tailhook commented 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?

1st1 commented 2 years ago

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.

tailhook commented 2 years ago

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.