skip to Main Content

I am working on adding support for Cypher clauses on Postgres psql. So far, we have added if clauses with string comparison to separate Cypher clauses from SQL clauses, with one parser for each. The HandleCypherCmds() function calls the Cypher parser, and the SendQuery() function calls the SQL parser.

/* handle cypher match command */
        if (pg_strncasecmp(query_buf->data, "MATCH", 5) == 0 ||
                pg_strncasecmp(query_buf->data, "OPTIONAL", 8) == 0 ||
                pg_strncasecmp(query_buf->data, "EXPLAIN", 7) == 0 ||
                pg_strncasecmp(query_buf->data, "CREATE", 6) == 0)
        {
            cypherCmdStatus = HandleCypherCmds(scan_state,
                                cond_stack,
                                query_buf,
                                previous_buf);

            success = cypherCmdStatus != PSQL_CMD_ERROR;

            if (cypherCmdStatus == PSQL_CMD_SEND)
            {
                success = SendQuery(convert_to_psql_command(query_buf->data));
            }
        }
        else
            success = SendQuery(query_buf->data);

The problem with this approach is that, for example, CREATE could be a SQL clause or a Cypher clause. Also, if the user inserts a typo in the clause, like "MATH" instead of "MATCH," the clause will not reach the parser. To solve this problem, I am thinking of a better way to differentiate a Cypher clause from a SQL one. Is there a way to do this in C?

2

Answers


  1. In case of any typos or errors in the query, it is recommended to inform the user through an error message. This way, the user can easily identify and correct any issues within the query.

    To differentiate between SQL clauses and Cypher clauses, you can use a delimiter, for instance, you can enclose all Cypher queries within a function called cypher(query) or BEGIN_CYPHER and END. Another way is a naming convention, such as marking Cypher functions with a prefix, like an underline: _MATCH.

    Login or Signup to reply.
  2. A method could be useful if you can try writing lexer and/or parser rules.

    For instance, you can have lexer rules to match keywords such as "CREATE" or "MATCH".

    Similarly, you can define the rules for parsing the token generated by the lexer and build an abstract syntax tree on the basis of the grammar rules.

    Hope these help.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search