Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Source SQL Parsers

tokern.io

Post reply on HN
Print view View original

31–40 of 103 posts

Re: Open Source SQL Parsers

#31

Post by manigandham »

userbinator wrote: post #16
tehlike wrote: post #5

Not related to parsers, but i find sql syntax so backwards. Listing columns first Then table Then join Then filter Then group bys Then limit The order of operations are out of whack and makes pipeline ing a little hard. I found this to be closer to LINQ way https://github.com/prql/prql I hope in near future databases will come with better query languages...

It was probably influenced by COBOL, i.e. designed to read like English.

In fact, SQL (structured query language) was originally called SEQUEL (structured English query language).

Re: Open Source SQL Parsers

#32

Post by newusertoday »

anitil wrote: post #6

I'd be interested to hear people's use cases for parsing SQL. The link talks about exploring sql history, but has anyone else got some interesting uses? A couple of times where I've needed to parse SQL I would typically write a module for sqlite3 and get it to do the parsing for me. But annoyingly I can't remember _why_ I did this or what I was trying to achieve.

auto generating api for frontend and backend that uses sql query and metadata.

Re: Open Source SQL Parsers

#33

Post by matteote »

anitil wrote: post #6

I'd be interested to hear people's use cases for parsing SQL. The link talks about exploring sql history, but has anyone else got some interesting uses? A couple of times where I've needed to parse SQL I would typically write a module for sqlite3 and get it to do the parsing for me. But annoyingly I can't remember _why_ I did this or what I was trying to achieve.

I use ANTLR4 and its rewriter to translate between two similar SQL dialects, for migration purposes.

Re: Open Source SQL Parsers

#34

Post by technion »

tehlike wrote: post #5

Not related to parsers, but i find sql syntax so backwards. Listing columns first Then table Then join Then filter Then group bys Then limit The order of operations are out of whack and makes pipeline ing a little hard. I found this to be closer to LINQ way https://github.com/prql/prql I hope in near future databases will come with better query languages...

This feels a lot like why Kusto was invented. It's very close to SQL, but written the other way around with the table name first, then the 'where', and finally the columns.

https://docs.microsoft.com/en-us/azure/data-explorer/kusto/q...

Re: Open Source SQL Parsers

#35

Post by technion »

anitil wrote: post #6

I'd be interested to hear people's use cases for parsing SQL. The link talks about exploring sql history, but has anyone else got some interesting uses? A couple of times where I've needed to parse SQL I would typically write a module for sqlite3 and get it to do the parsing for me. But annoyingly I can't remember _why_ I did this or what I was trying to achieve.

I'm still waiting for a very simple proxy where I can write rules like "DELETE statements must come with a WHERE".

Re: Open Source SQL Parsers

#36

Post by orangepanda »

technion wrote: post #35
anitil wrote: post #6

I'd be interested to hear people's use cases for parsing SQL. The link talks about exploring sql history, but has anyone else got some interesting uses? A couple of times where I've needed to parse SQL I would typically write a module for sqlite3 and get it to do the parsing for me. But annoyingly I can't remember _why_ I did this or what I was trying to achieve.

I'm still waiting for a very simple proxy where I can write rules like "DELETE statements must come with a WHERE".

Oh this doesnt need a condition, let me just WHERE 1=1

Re: Open Source SQL Parsers

#37

Post by technion »

orangepanda wrote: post #36
technion wrote: post #35

Earlier quoted context omitted.

I'm still waiting for a very simple proxy where I can write rules like "DELETE statements must come with a WHERE".

Oh this doesnt need a condition, let me just WHERE 1=1

Yes, but deliberate malfeasance isn't the usual problem when this occurs, as much as some variant of "the BI person hit run before the query was finished".

Re: Open Source SQL Parsers

#39

Post by gunnarmorling »

anitil wrote: post #6

I'd be interested to hear people's use cases for parsing SQL. The link talks about exploring sql history, but has anyone else got some interesting uses? A couple of times where I've needed to parse SQL I would typically write a module for sqlite3 and get it to do the parsing for me. But annoyingly I can't remember _why_ I did this or what I was trying to achieve.

For Debezium (a change data capture solution) we parse SQL for some of the connectors in order to keep track of the schema of captured tables as DDL statements are executed.

Events we receive e.g. from MySQL aren't fully self-descriptive, you need to know the schema they adhere to in order to interpret them. As table schemas can change over time and as -- due to the async nature of streaming the transaction log -- we may receive change events produced from before a table's schema was changed, we cannot simply query the current table schema. Parsing incoming DDL events is the only way for keeping the connector's view on the schema in sync.

Re: Open Source SQL Parsers

#40

Post by tehlike »

manigandham wrote: post #31
userbinator wrote: post #16

Earlier quoted context omitted.

It was probably influenced by COBOL, i.e. designed to read like English.

In fact, SQL (structured query language) was originally called SEQUEL (structured English query language).

I find prql more English for some reason...
Post reply on HN