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

PRQL – A proposal for a better SQL

github.com

Post reply on HN
Print view View original

151–160 of 302 posts

Re: PRQL – A proposal for a better SQL

#151

Post by [deleted] »

taeric wrote: post #127
emteycz wrote: post #107

Earlier quoted context omitted.

I'd agree if there was any way whatsoever of fixing this issue, but there simply isn't. The editor can't even begin to guess what you might want until you write your FROM.

Maybe in gigantic systems with more tables than makes sense. Realistically, all of the columns available in a database can be fit in memory with ease. Then, the ide could basically fill my from out for me, based on what I'm asking for. Can even suggest what join I will need, if I list columns from multiple tables.

[deleted]

Re: PRQL – A proposal for a better SQL

#152

Post by bchammer »

This looks like a turing-complete language if you add function. One benefit or current SQL is that it can (and is) often rewritten to be executed more efficiently. This requires a simpler and declarative model - far from a programming language.

If you want simple 'forward declaration' take a look at the SQL WITH clause.

Re: PRQL – A proposal for a better SQL

#153

Post by larodi »

eatonphil wrote: post #6

I'm really excited about languages that build on or are compiled to SQL, in the long-term (because I think it will take a very long time to build adoption). The ones that particularly excite me are shorthands for SQL, even though their heavy use of symbols may be a detriment. One particular use case is in easily defining static authorization policy-queries that are backed by database data plus and have request variab…

in a way SQL is Prolog and all reasoning for improvement of SQL should start from Prolog, because is where SQL started from. the expressive power of both languages is theoretically the same, even though SQL is much more comprehensible. but then again - certain complex task turn SQL in difficult-to-comprehend series of nested declarative operations on algebraic sets.

Re: PRQL – A proposal for a better SQL

#154

Post by taeric »

tester756 wrote: post #148
taeric wrote: post #147

Earlier quoted context omitted.

500 times 50 is still not a big number. And you could do decent statistical suggestions on the current columns in. Good intelligent suggestions is, of course, helpful. And I agree that suggesting one of 500 is easier than the other. That said, neither is hard for a computer. And even asking friends what table I want will often be done with starting with the actual columns I want.

On the other hand I don't see why it couldnt work both ways if you start query with SELECT MiddleName then you could receive auto complete thats adds "FROM Users" and moves your cusor after MiddleName. if you start query with FROM Users SELECT _ and know intellisense drops list of columns

Agreed. I'm really just arguing that it doesn't have to be from first.

Re: PRQL – A proposal for a better SQL

#155

Post by politician »

I prefer "from first". When I write a SQL query, 99 times out of 100, I'll start with "select * from", then fill in the query, then go back and select the columns. After a few basic joins, "easy" column names have probably grown aliases or have been subsumed entirely. For me, "select * from" is automatic.

Re: PRQL – A proposal for a better SQL

#156

Post by oblio »

To the author, if he's reading this. I wish you luck! To get this adopted, try to make it modular so maybe it can be made a core module of PostgreSQL, MariaDB, MySQL. If you somehow get into those 3 I wouldn't be surprised if Oracle, SQL Server and DB2 integrate it themselves just to keep up.

Ah, Presto could be another popular target.

It's a huge effort but something which could have colossal payback.

Re: PRQL – A proposal for a better SQL

#157

Post by adamrezich »

keithnz wrote: post #149
inglor wrote: post #113

Earlier quoted context omitted.

You would think that but having used both I find writing Kusto/KQL much smoother, neater and faster and if I have to choose between writing a query in either one I'd pick KQL. I understand this is just an opinion but it's an opinion held by everyone in my org who writes both. Theoretical correctness loses to pragmatism a lot and I'd read the KQL every day. Look at the examples at https://docs.microsoft.com/en-us/azur…

now if MS made a KQL -> TSQL or support it natively in SQL Server, that would be great :)

yes please!!

Re: PRQL – A proposal for a better SQL

#158

Post by twic »

oblio wrote: post #156

To the author, if he's reading this. I wish you luck! To get this adopted, try to make it modular so maybe it can be made a core module of PostgreSQL, MariaDB, MySQL. If you somehow get into those 3 I wouldn't be surprised if Oracle, SQL Server and DB2 integrate it themselves just to keep up. Ah, Presto could be another popular target. It's a huge effort but something which could have colossal payback.

This language transpiles to SQL, so it can be implemented entirely client-side. No need for modules for the database engines, just wrappers round the clients.

Re: PRQL – A proposal for a better SQL

#159

Post by twic »

maximilianroos wrote: post #51
tfehring wrote: post #17

Very cool! A couple questions/suggestions off the top of my head: 1. Did you consider using a keyword like `let` for column declarations, e.g. `let gross_salary = salary + payroll_tax` instead of just `gross_salary = salary + payroll_tax`? It's nice to be able to scan for keywords along the left side of the window, even if it's a bit more verbose. 2. How does it handle the pattern where you create two moderately comp…

> 2. How does it handle the pattern where you create two moderately complex CTEs or subqueries (maybe aggregated to different levels of granularity) and then join them to each other? I always found that pattern awkward to deal with in dplyr - you have to either assign one of the "subquery" results to a separate dataframe or parenthesize that logic in the middle of a bigger pipeline. Maybe table-returning functions wo…

My gut reaction is that if we have "from first" then maybe we should have to "to last":

  from employees
  sort tenure
  take 50
  as newest_employees
  
  from newest_employees
  join salary [id]
  select [name, salary]
Post reply on HN