[FORMATTING] When the language is postgres, executing "select * from test. [User]" will result in an error message

[zbenj]

Input data

Which SQL and options did you provide as input?

select * from  test.[User] 

Actual Output

none result

Console Output

Uncaught Error: Parse error at token: [ at line 1 column 21
Unexpected OPEN_PAREN token: {"type":"OPEN_PAREN","raw":"[","text":"[","start":20}. Instead, I was expecting to see one of the following:

A LINE_COMMENT token based on:
    comment →  ● %LINE_COMMENT
    _$ebnf$1 → _$ebnf$1 ● comment
    _ →  ● _$ebnf$1...

at Parser.feed (nearley.js:343:27)
    at Object.parse (createParser.ts:33:34)
    at Formatter.parse (Formatter.ts:41:49)
    at Formatter.format (Formatter.ts:33:22)
    at formatDialect (sqlFormatter.ts:94:57)
    at formatSqlValue (index.vue:193:23)
    at formatValue (index.vue:170:9)
    at callWithErrorHandling (runtime-core.esm-bundler.js:158:18)
    at callWithAsyncErrorHandling (runtime-core.esm-bundler.js:166:17)
    at SVGSVGElement.invoker (runtime-dom.esm-bundler.js:595:5)

Usage

• How are you calling / using the library? import { formatDialect,sql,plsql,transactsql,postgresql } from 'sql-formatter' formatDialect(sqlVal, { dialect: postgresql})
• What SQL language(s) does this apply to?
• postgresql
• Which SQL Formatter version are you using?
• 13.0.4

[nene]

This is to be expected because that's not valid PostgreSQL code.

[nene]

So you would expect a different kind of exception to be thrown?

[zbenj]

So you would expect a different kind of exception to be thrown?

Yes,It's better this way because I don't know if there are any other errors, so I wouldn't know how to differentiate them when using try-catch.

[nene]

So, instead of getting an instance of Error you would like to something like an instance of ParseError to be thrown?

That's a possible change. But it'll have to wait until next major release as it would be a breaking change.

Though I'm really in the same boat as you. I don't know what other kinds of errors might come from the Nearley parser. I'd have to catch this parse error from Nearley and re-throw it as some other type of error. I'm not quite sure whether it would be better to wrap the underlying parser errors or leave them as-is.

I think a simpler approach for you might be to simply check if error.message starts with text: Parse error. This way you can catch both parsing errors from sql-formatter itself and from the underlying Nearley parser.

See sqlFormatter.test.ts for an overview of what kind of errors you can expect.

[zbenj]

Ok,I got it,Thanks! I have currently processed it in the simple way you mentioned.