Snowflake#93
Conversation
rathboma
left a comment
There was a problem hiding this comment.
I think we probably have to deal with the Snowflake keywords leaking into other dialects
| 'TRIGGERS', | ||
| 'VARIABLES', | ||
| 'WARNINGS', | ||
| 'MERGE', |
There was a problem hiding this comment.
Are these keywords valid for every dialect? Should we be scoping these somehow?
There was a problem hiding this comment.
looks like the addition of LIST even required a test change?
| 'PUT', | ||
| 'GET', | ||
| 'LIST', | ||
| 'LS', |
There was a problem hiding this comment.
certainly feels like we might need to keep snowflake-specific keywords out of the global tokenizer list and scope them based on dialect
| return createBlockStatementParser(options); | ||
| } | ||
| break; | ||
| case 'MERGE': |
There was a problem hiding this comment.
Are any of these Snowflake specific? Looks like we dialect-gate some below, but not these presumably because they're widely supported?
There was a problem hiding this comment.
I'm pretty sure that PartiQL doesn't support a lot of these for example
| describe('with strict disabled', () => { | ||
| it('should parse if first token is unknown', () => { | ||
| const actual = parse('LIST * FROM foo', false); | ||
| const actual = parse('FOOBAR * FROM foo', false); |
There was a problem hiding this comment.
see we had to change it! This is invalid SQL in a bunch of dialects I think. Don't think LIST is AnsiSQL or supported by postgresql, and I don't think MySQL either?
Snowflake implementation. Also adds some keywords/statements that seemed to be missing (
USE,COPY,MERGE, etc)