This library is very promising — thanks for releasing it!
While testing against Postgres, I noticed a possible issue with how some GiST operators are parsed or rendered.

To reproduce, add the following test to test/adapters/postgres_test.exs:

describe "operators" do
  ...
  test "@>" do
    assert "where id @> transaction_timestamp()" == to_string(~SQL[where id @> transaction_timestamp()])
  end
end

Which fails with:

  1) test operators @> (SQL.Adapters.PostgresTest)
     test/adapters/postgres_test.exs:267
     Assertion with == failed
     code:  assert "where id @> transaction_timestamp()" == to_string(~SQL[where id @> transaction_timestamp()])
     left:  "where id @> transaction_timestamp()"
     right: "where id @ > transaction_timestamp ()"
     stacktrace:
       test/adapters/postgres_test.exs:268: (test)

As shown, to_string/1 inserts an unexpected space between @ and > and between the function name and its parentheses. This breaks the intended SQL syntax.

I'm not sure of the exact root cause, but would appreciate if someone familiar with the parser could take a look.
Would it also be possible to support all of PostgreSQL's built-in GiST operators?

Thanks!