should bracket quotation (like sqlserver supports it) be removed to be able to support array constructs

[wumpz]

At the moment JSqlParser supports quotation like [colname]. This is the reason it cannot support simple array constructs using brackets as well.

As the bracket quotation, IMHO, should be replaced by double quotes.

Should the bracket quotation be removed to get the way free to arrays?

[wumpz]

So no opinion from JSqlParsers users so far.

I tend to do extactly this, removing bracket quotation for version 2.0 of JSqlParser, to do array processing.

[CodingFabian]

since we have seen arrays but not this quotation, I would vote for yes

[wumpz]

So be it. Starting with version 2 JSqlParser drops support for bracket quotation.

[yeswaydude]

There is a huge history of SQL that has continued to run against SQL Server for decades that uses the square bracket-quoted identifiers. If I recall correctly, some SQL Server syntax can only be accessed via the square brackets (i.e. FOR XML directives).

Does someone have an example of array syntax with an explanation of how support for that precludes support for square bracket-quoted identifiers?

[wumpz]

Some would be (from Postgresqls manual (http://www.postgresqltutorial.com/postgresql-array/) ):

SELECT
 id,
 name,
 phones [ 2 ]
FROM
 contacts
WHERE
 id = 3;

SqlServer would interpret [2] as an alias, which is perfectly fine. Nevertheless array access using brackets is more or less standardized as well within most programming languages.

[gordthompson]

IMO it certainly would be a shame if "drops support for bracket quotation" meant that v2.x would be completely unable to parse T-SQL like

SELECT [column name] FROM [table name];

As mentioned in a previous comment, like it or not there is an enormous amount of T-SQL out there that uses [column name] instead of "column name", despite what ANSI (or others) might say.

[wumpz]

I will happily reopen this issue. I as well was surprised, that so little seemed to be interested. I want a discussion. I want suggestions how to implement it. I would keep both, if it works, but I assume is collides to much:

select a [b]

is using sqlserver an alias and using e.g. postgres an array access.

[gordthompson]

If it is a question of dropping the currently-supported [bracket quoting] in order to support array constructs then one possibility might be to add the option to specify something like tsqlQuoting when creating a parser. If tsqlQuoting is true then [thing] would be a table/column reference, but if it is false then we may be able to safely assume that [thing] is an array reference (because a quoted table/column name would presumably be the ANSI-quoted "thing").

[wumpz]

One can achieve this by semantic lookahead?

[gordthompson]

One can achieve this by semantic lookahead?

Maybe. Automatically detecting [column_name] vs. [array_reference] would certainly be nice if that is practical given the variety of SQL dialects out there. In other words, is it reasonable to expect that we could define parsing rules (possibly including lookahead) to reliably differentiate between the two cases for an arbitrary SQL statement without prior knowledge of the dialect?

Providing an explicit hint would definitely make it easier for the parser, in any case.