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

Literate SQL

modern-sql.com

Post reply on HN
Print view View original

1–10 of 100 posts

Re: Literate SQL

#2

Post by mshenfield »

I came to this page looking for ways to parameterize and re-use raw SQL. with (and create view for multiple queries) fulfill the case where the unit of reuse is a filtered view on one or more tables.

Re: Literate SQL

#4

Post by rikkipitt »

mshenfield wrote: post #2

I came to this page looking for ways to parameterize and re-use raw SQL. with (and create view for multiple queries) fulfill the case where the unit of reuse is a filtered view on one or more tables.

Great timing for me on this, thanks for sharing!

Re: Literate SQL

#5

Post by nerdponx »

I wish CTEs ("common table expression", i.e. a "with clause") had the same performance as a subquery in PSQL. I always assumed they'd be implemented as a kind of macro that expanded to a subquery. Is there a good reason for this distinction?

For that matter, having some kind of SQL-oriented macro/preprocessor language would be fantastic. I guess GPP (General Preprocessor, https://logological.org/gpp) is always an option.

Re: Literate SQL

#6

Post by gjvc »

nerdponx wrote: post #5

I wish CTEs ("common table expression", i.e. a "with clause") had the same performance as a subquery in PSQL. I always assumed they'd be implemented as a kind of macro that expanded to a subquery. Is there a good reason for this distinction? For that matter, having some kind of SQL-oriented macro/preprocessor language would be fantastic. I guess GPP (General Preprocessor, https://logological.org/gpp ) is always an op…

For the uninitiated, what is GPP ?

Re: Literate SQL

#7

Post by [deleted] »

nerdponx wrote: post #5

I wish CTEs ("common table expression", i.e. a "with clause") had the same performance as a subquery in PSQL. I always assumed they'd be implemented as a kind of macro that expanded to a subquery. Is there a good reason for this distinction? For that matter, having some kind of SQL-oriented macro/preprocessor language would be fantastic. I guess GPP (General Preprocessor, https://logological.org/gpp ) is always an op…

[deleted]

Re: Literate SQL

#8

Post by caseymarquis »

It's critical to have a good understanding of SQL, but once you do, ORMs with a functional syntax solve this problem for many of us. I know it's not possible for some people to use ORMs as they can't risk the ORM making a performance mistake, but I think the solution is to improve ORMs to the point that writing raw SQL is akin to writing assembly instead of using a higher level language.

That said, we're not there yet. Using an ORM in 2017 without understanding what SQL you want it to produce IS NOT OKAY. Please learn SQL if you're going to use an ORM, and understand the SQL you are producing with the ORM.

Summed up, if you can, use an ORM to solve this problem.

Re: Literate SQL

#9

Post by mshenfield »

rikkipitt wrote: post #4
mshenfield wrote: post #2

I came to this page looking for ways to parameterize and re-use raw SQL. with (and create view for multiple queries) fulfill the case where the unit of reuse is a filtered view on one or more tables.

Great timing for me on this, thanks for sharing!

np!

Re: Literate SQL

#10

Post by okket »

gjvc wrote: post #6
nerdponx wrote: post #5

I wish CTEs ("common table expression", i.e. a "with clause") had the same performance as a subquery in PSQL. I always assumed they'd be implemented as a kind of macro that expanded to a subquery. Is there a good reason for this distinction? For that matter, having some kind of SQL-oriented macro/preprocessor language would be fantastic. I guess GPP (General Preprocessor, https://logological.org/gpp ) is always an op…

For the uninitiated, what is GPP ?

Closest guess: General-purpose PreProcessor

https://github.com/logological/gpp/

Post reply on HN