Incorrect parsing of Postgres GiST operator @> adds unexpected whitespace

[ibarchenkov]

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!

[Schultzer]

You are correct, Gist operators are currently not handled by the lexer if you’re down for it you can push a PR and add it here: https://github.com/elixir-dbvisor/sql/blob/main/lib/mix/tasks/sql.gen.parser.ex#L425

You would properly have to add code other places as well, I’m currently working on a bigger refactoring of the generator. But that is still gonna take some time.