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

Show HN: We open sourced our entire text-to-SQL product

github.com

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Show HN: We open sourced our entire text-to-SQL product

#51

Post by skydhash »

twojacobtwo wrote: post #47
saigal wrote: post #39

Earlier quoted context omitted.

hmm not sure I understand the question

I think GP meant 'where or from whom have you seen/heard demand for this?'. Weirdly, I was just thinking about using an LLM to form sql queries for me, because I've forgotten much of what I knew. First time I had that thought and 5 minutes later, this fascinating idea rolls into my feed to pull me in further. I know I'm not exactly the target audience, but now I'm intrigued. I went through a coding/design bootcamp a…

> I could see it being used in a tool for new devs or those who've focused on a JS stack and need some help with SQL

Or they could buy a book like Learning SQL. Or spend a weekend on Youtube.

Re: Show HN: We open sourced our entire text-to-SQL product

#53

Post by freeone3000 »

throwaway115 wrote: post #52

What guarantees do you offer with query security if I turn this over to an end user? How do I keep them only accessing their own data?

Any number of database namespacing techniques already present in postgresql can prevent this. Link the user sign-on to a DB user and you’re gold.

Re: Show HN: We open sourced our entire text-to-SQL product

#54

Post by saigal »

skydhash wrote: post #51
twojacobtwo wrote: post #47

Earlier quoted context omitted.

I think GP meant 'where or from whom have you seen/heard demand for this?'. Weirdly, I was just thinking about using an LLM to form sql queries for me, because I've forgotten much of what I knew. First time I had that thought and 5 minutes later, this fascinating idea rolls into my feed to pull me in further. I know I'm not exactly the target audience, but now I'm intrigued. I went through a coding/design bootcamp a…

> I could see it being used in a tool for new devs or those who've focused on a JS stack and need some help with SQL Or they could buy a book like Learning SQL . Or spend a weekend on Youtube.

allow me to clarify.. Dataherald isn't intended for developers because they don't know SQL, it's intended for developers who want to build text to SQL into their products

Re: Show HN: We open sourced our entire text-to-SQL product

#56

Post by warkdarrior »

chx wrote: post #50
saigal wrote: post #41

Earlier quoted context omitted.

i agree that there will be "early adopter" type use cases and others that might take a while (e.g. healthcare with hipaa compliance) it is still the early days. goal is to give the developer tools to do this easier.

Enough of this weasel talk. It's not the early days. Not by a country mile. To quote Cory Doctorow > I don’t see any path from continuous improvements to the (admittedly impressive) ”machine learning” field that leads to a general AI any more than I can see a path from continuous improvements in horse-breeding that leads to an internal combustion engine. You can counter it doesn't necessarily need an AGI here but tha…

Indeed, AI is not marketed as a BS generator, just as HTTP is not marketed as a spam/ad/fraud/harassment transport protocol. All technologies are dual-use, deal with it!

Re: Show HN: We open sourced our entire text-to-SQL product

#57

Post by throwaway115 »

freeone3000 wrote: post #53
throwaway115 wrote: post #52

What guarantees do you offer with query security if I turn this over to an end user? How do I keep them only accessing their own data?

Any number of database namespacing techniques already present in postgresql can prevent this. Link the user sign-on to a DB user and you’re gold.

What? How does that ensure user 123 only generates LLM queries that constrain on rows where user=123?

Re: Show HN: We open sourced our entire text-to-SQL product

#58

Post by aazo11 »

throwaway115 wrote: post #52

What guarantees do you offer with query security if I turn this over to an end user? How do I keep them only accessing their own data?

We recommend users leverage row-level security features built into modern RDBMS so the query results only return data for a given user.

You can read more on how to do that on Postgres here https://www.2ndquadrant.com/en/blog/application-users-vs-row...

Re: Show HN: We open sourced our entire text-to-SQL product

#59

Post by aazo11 »

throwaway115 wrote: post #57
freeone3000 wrote: post #53

Earlier quoted context omitted.

Any number of database namespacing techniques already present in postgresql can prevent this. Link the user sign-on to a DB user and you’re gold.

What? How does that ensure user 123 only generates LLM queries that constrain on rows where user=123?

As I wrote on the original thread, we recommend using the RDBMS row-level security features.

This blog discusses how to do that on Postgres

https://www.2ndquadrant.com/en/blog/application-users-vs-row...

Re: Show HN: We open sourced our entire text-to-SQL product

#60

Post by throwaway115 »

aazo11 wrote: post #58
throwaway115 wrote: post #52

What guarantees do you offer with query security if I turn this over to an end user? How do I keep them only accessing their own data?

We recommend users leverage row-level security features built into modern RDBMS so the query results only return data for a given user. You can read more on how to do that on Postgres here https://www.2ndquadrant.com/en/blog/application-users-vs-row...

Where do you recommend this? It sounds dangerous for databases that do not implement RLS, like Mysql, MariaDb, Sqlite. I think you should highlight that very clearly somewhere.
Post reply on HN