hasura / hasura/graphql-engine

can WhereExp expose the operators in the underlying postgres?

Open
#8,325 0 comments 1 reaction 0 assignees View on GitHub
k/enhancement
Dominant language
TypeScript
Stars
32.1k
Forks
3k
PR merge metrics
PR metrics pending

Description

### Is your proposal related to a problem?

I'm adding fuzzy search capabilities according to the examples in the [docs](https://hasura.io/docs/latest/graphql/core/databases/postgres/schema/custom-functions.html#example-fuzzy-match-search-functions) , [blog](https://hasura.io/blog/full-text-search-with-hasura-graphql-api-postgres/) and other sources.
Now, our fuzzy search relies on multiple fields and relations in our schema.
After I added the required extension:
```
CREATE EXTENSION IF NOT EXISTS pg_trgm;
```
I can execute this query:
```
SELECT *
FROM public.user
WHERE search % "name"
```
Actually I can now use the similarity operator on any column that I want.
Indexes increase performance of course but are not required.

Unfortunately Hasura doesn't expose this operator in WhereExp, so fuzzy search on each permutation of a set of columns will require it's own SQL function, instead of supporting the freedom to decide during query construction like this:
```
query ($q: String){
data: post (where: {
_or:[
{title:{_%:$q}}
{content:{_%:$q}}
{tags: {
name: {_%:$q}
}}
{user: {
first_name: {_%:$q}
last_name: {_%:$q}
}}
]
})...
```
> NOTE: `_%` in the above example refer to the new `%` operator added to postgres

### Describe the solution you'd like

Exposing all of the available underlying operators, OR (less favorable) allowing for unsafe operator input that will be directly translate to the underlying operator will support the aforementioned freedom.

### Describe alternatives you've considered

> OR (less favorable) allowing for unsafe operator input that will directly translate to the underlying operator

### If the feature is approved, would you be willing to submit a PR?

I'm familiar with haskell but not at production level code, plus if the first option is not possible (because it's impossible to derive from a postgres instance the available operators) then the second option is a potential security risk.
But, with the appropriate supervision and guidance I'm willing to take on the challenge :)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.