Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for MS SQL? #32

Open
stoyanov-x opened this issue Mar 28, 2018 · 4 comments
Open

Support for MS SQL? #32

stoyanov-x opened this issue Mar 28, 2018 · 4 comments

Comments

@stoyanov-x
Copy link

Are there any plans for MS SQL support? I think there are quite a few companies which could benefit from this.

@dlthomas
Copy link
Contributor

I don't expect Uber has enough interest in MS SQL support to implement it internally, but I'm sure they'd be happy to merge new dialects if provided (@h4v0kh3l1 can you confirm or deny? :D). FWIW, I'm happy to provide guidance for anyone taking this on (for MS SQL or any other dialect).

@h4v0kh3l1
Copy link
Contributor

That is accurate. We don't have a use case for MS SQL at Uber, but it is certainly within the scope of this project to expand our supported dialects.

And likewise with @dlthomas, I can also provide guidance on doing so.

@etrabelsi
Copy link

@dlthomas @h4v0kh3l1 Hi guys i would like to get some guidance on how can i implement Redshift/Spark SQL Dialect.

@h4v0kh3l1
Copy link
Contributor

@etrabelsi As a general high-level approach, start with copying one of the dialect parsers similar to Redshift/Spark SQL, and modifying the language features as the respective SQL documentation says. The tests contain a wealth of statements that should or should not pass parsing, and you'll want to modify those to fit the dialect.

It'll be an action item on me to publish guidelines for developing new dialect parsers, and for now let's start with the following:

  • each dialect should have its own feature branch while it's under development.
  • if you need to add custom datatypes, try adding to the parser's Type.hs before adding to the common typesystem.
  • you might encounter moments where the dialect needs a very different representation than what's in common (e.g. Hive's use of file locations as a stand-in for tables when loading). Please first open up an issue so everyone else is aware of and can start folding solutions into the existing ecosystem.

As the package uploader, we'll need to work out the publishing process once the dialect is ready to roll, but we can defer to when we get there.

@dlthomas LMK if I missed something.

Hopefully that's enough to get you started. If you have follow-ups or more specific questions, let's open a new issue and start a conversation there, so we can keep this issue on MS SQL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants