0

I am using Teiid's query parser. For the sql used in my below given code, although the identifiers are ansi-quoted, query parser is not splitting them into schema, tableName and FieldName correctly.

Here is my Code:

String sqlToParse = "Select "dbo.mydbo"."employee.info".id from "dbo.mydbo"."employee.info""

Query query = (Query)QueryParser.getQueryParser().parseCommand(sqlToParse, new ParseInfo());

In the above sql:

Schema name is dbo.mydbo

Table name is employee.info

Field name is id

During parsing, it looks like Teiid Parser is first removing the double quotes after which the fully qualified field name will become dbo.mydbo.employee.info.id. After this it splits based on dot(.)

String before first dot is taken as GroupSymbol.qualifier(schema name): dbo

String after last dot is taken as the ElementSymbol.shortName(field name): id

And rest of the string between first and last dot is taken as GroupSymbol.shortName(table name): mydbo.employee.info

The above split is giving incorrect results. The split should consider the quotes when identifiers are quoted.

Am I missing something in my code or is there some setting missing in ParseInfo due to which Teiid parser is not considering the quotes while splitting the identifiers.

Pluto
  • 853
  • 1
  • 8
  • 28
M S
  • 1
  • 1

1 Answers1

0

Am I missing something in my code or is there some setting missing in ParseInfo due to which Teiid parser is not considering the quotes while splitting the identifiers.

For legacy reasons the parser does not appropriately consider how quoting breaks up an identifier. I believe the original intention was to allow for importing of schema qualified tables, which would have a teiid name along the lines of "schema"."source-schema.table-name", that could still be queried with what looked like source sql - select ... from "source-schema"."table-name". There should be several warnings in the docs about this laxity in the parser.

After resolving the command / symbols will generally be what you expect - with the potential problem in the scenario where there is a fully qualified name that is a suffix for another object. We'll currently prefer the fqn form rather than throw an ambiguous exception.

For example in schema x: create foreign table "y" (col string); create foreign table "x.y" (col string);

Then 'select * from "x.y"' would currently resolve to "x"."y", but it would be better if it were ambiguous.

Steven Hawkins
  • 538
  • 1
  • 4
  • 7