5 ms·

Yes, parsing sql is not straightforward as there are many dialects. But the rest of the article is confusing. There’s not very many instances where someone nee

by bfung 4y ago

Yes, parsing sql is not straightforward as there are many dialects. But the rest of the article is confusing. There’s not very many instances where someone needs to parse sql - there are ORM libraries that generate the relevant sql dialect. This has been the case since the early 2000s; see Hibernate. And for C#, there’s LINQ to SQL. The last sentence then goes into the “sell”: if you need help parsing sql, contact us at xyz…

zasdffaa 4y ago
> there are ORM libraries that generate the relevant sql dialect. This has been the case since the early 2000s; see Hibernate. And for C#, there’s LINQ to SQL. That's generating SQL. Parsing is going from text to the AST; the reverse of what you're saying. Maybe I'm confused.
- bfung 4y ago
  yes, apologies, I skipped ahead. Parsing: "There’s not very many instances where someone needs to parse sql" The only use cases would be building your own database/query optimizer and having SQL be the API. There are plenty of other tools already to help programming languages interface w/SQL, give compile time checks, test, generate SQL, etc. Build the parser for fun, sure, but don't then offer consulting services on an article that didn't really specify a business problem or outcome and just talked about tech stuff.
  - zasdffaa 4y ago
    He actually lists at the end as an alternatives to his consulting: Consider if you can use existing tools or libraries to process SQL code. Some of them even support multiple SQL-dialects or multiple programming languages. If you can use any of them for your needs they should be your first option If you want to build a solution in-house you may consider starting from the few ANTLR grammars available for the major SQL databases. They can really help you get started in parsing SQL > There are plenty of other tools already to help ... give compile time checks Which are these? > ..that didn't really specify a business problem or outcome and just talked about tech stuff. The business problem is to build an sql parser. the outcome being an SQL parser. It's clear enough and it's something I had to do. Your criticisms are unreasonable.
samatman 4y ago
I can think of one: deriving a type for a prepared statement. To do that you have to parse the schema to get the table types and work backward. That lets the analyzer decide what sorts of data may be legally passed to a given prepared statement, and produce type failures at compile time. There are more, that's the first which came to mind. Disclosure: I'm writing an SQLite PEG for a number of reasons which might hypothetically include that one.

by bfung 4y ago

zasdffaa 4y ago

> there are ORM libraries that generate the relevant sql dialect. This has been the case since the early 2000s; see Hibernate. And for C#, there’s LINQ to SQL. That's generating SQL. Parsing is going from text to the AST; the reverse of what you're saying. Maybe I'm confused.

bfung 4y ago
yes, apologies, I skipped ahead. Parsing: "There’s not very many instances where someone needs to parse sql" The only use cases would be building your own database/query optimizer and having SQL be the API. There are plenty of other tools already to help programming languages interface w/SQL, give compile time checks, test, generate SQL, etc. Build the parser for fun, sure, but don't then offer consulting services on an article that didn't really specify a business problem or outcome and just talked about tech stuff.
- zasdffaa 4y ago
  He actually lists at the end as an alternatives to his consulting: Consider if you can use existing tools or libraries to process SQL code. Some of them even support multiple SQL-dialects or multiple programming languages. If you can use any of them for your needs they should be your first option If you want to build a solution in-house you may consider starting from the few ANTLR grammars available for the major SQL databases. They can really help you get started in parsing SQL > There are plenty of other tools already to help ... give compile time checks Which are these? > ..that didn't really specify a business problem or outcome and just talked about tech stuff. The business problem is to build an sql parser. the outcome being an SQL parser. It's clear enough and it's something I had to do. Your criticisms are unreasonable.

samatman 4y ago

I can think of one: deriving a type for a prepared statement. To do that you have to parse the schema to get the table types and work backward. That lets the analyzer decide what sorts of data may be legally passed to a given prepared statement, and produce type failures at compile time. There are more, that's the first which came to mind. Disclosure: I'm writing an SQLite PEG for a number of reasons which might hypothetically include that one.