Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-321

Allow library users to replace implementation of CompoundIdentifier in SQL Parser

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.9.0-incubating
    • Component/s: None
    • Labels:
      None

      Description

      This will allow users to support alternative identifier constructs.

        Activity

        Hide
        julianhyde Julian Hyde added a comment -

        Can you describe why? It's often better for a parser to record what it sees, and have the validator to introduce semantics (since it has type information and other semantic context).

        Show
        julianhyde Julian Hyde added a comment - Can you describe why? It's often better for a parser to record what it sees, and have the validator to introduce semantics (since it has type information and other semantic context).
        Hide
        julianhyde Julian Hyde added a comment -

        That said, implementing OPTIQ-207 will require more flexible handling of '.'.

        Show
        julianhyde Julian Hyde added a comment - That said, implementing OPTIQ-207 will require more flexible handling of '.'.
        Hide
        jnadeau Jacques Nadeau added a comment -

        We do it to allow sugared syntax using the dot for item operators and dynamic schema, supporting things such as "tbl.cola.colb[4].value" => tbl.cola['colb'][4]['value']

        Show
        jnadeau Jacques Nadeau added a comment - We do it to allow sugared syntax using the dot for item operators and dynamic schema, supporting things such as "tbl.cola.colb [4] .value" => tbl.cola ['colb'] [4] ['value']
        Hide
        julianhyde Julian Hyde added a comment - - edited

        I think in that case even the base parser should generate calls to the dot operator.

        There are uses of CompoundIdentifier() outside of scalar expressions – e.g. INSERT INTO CompoundIdentifier() ... – and I think these should remain. But an expression, e.g. e.name, should be parsed as SqlCall(DOT, SqlIdentifier("e"), SqlIdentifier("name")). And then the validator should figure out what the DOT means.

        Show
        julianhyde Julian Hyde added a comment - - edited I think in that case even the base parser should generate calls to the dot operator. There are uses of CompoundIdentifier() outside of scalar expressions – e.g. INSERT INTO CompoundIdentifier() ... – and I think these should remain. But an expression, e.g. e.name, should be parsed as SqlCall(DOT, SqlIdentifier("e"), SqlIdentifier("name")) . And then the validator should figure out what the DOT means.
        Show
        julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/incubator-optiq/commit/55d67e20 .
        Hide
        julianhyde Julian Hyde added a comment -

        Close issues resolved in release 0.9.0-incubating (2014-08-25).

        Show
        julianhyde Julian Hyde added a comment - Close issues resolved in release 0.9.0-incubating (2014-08-25).

          People

          • Assignee:
            jnadeau Jacques Nadeau
            Reporter:
            jnadeau Jacques Nadeau
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development