4 ms·

But that's not a function of the language itself. If there were SQL debuggers you could step through a big query with, debugging SQL would be a lot easier. As

But that's not a function of the language itself. If there were SQL debuggers you could step through a big query with, debugging SQL would be a lot easier. As it is, you often have to take the whole damn thing apart from the inside to see what's going on, then put it all back together again. That's... suboptimal, to say the least.

masklinn 4y ago
> But that's not a function of the language itself. It is tho, SQL is a declarative language, so the execution model is largely opaque, by language design. But even if it were solely an implementation detail, Closi would still be wrong: they literally stated that “it’s not any better” to try debugging a 100 lines python script than a 100 lines query. > As it is, you often have to take the whole damn thing apart from the inside to see what's going on, then put it all back together again. That's... suboptimal, to say the least. Which is the point? Sounds like you agree that it is significantly easier to debug a 100 lines python script than a 100 lines SQL query.
- ltbarcly3 4y ago
DemocracyFTW2 4y ago
I often watch in horror what some people suggest is 'good SQL'. You even find plenty of those humongous multi-hundred-line beasts on the official PostgreSQL wiki, a single statement going over several pages if you were to print it out. Sure that's hard to debug. What I do in such cases is using many intermediate views, sometimes just named like `_foobar_010`, `_foobar_020` and so on, and a single `create (materialized) view foobar ... select from _foobar_120 ...`. That way, I can rely on the DB caring for basic structural soundness, giving error messages that are better localized than "something is wrong near ','", and I can visually (or, indeed, programmatically) debug all the intermediate steps.
- ltbarcly3 4y ago
  This is just obviously selection bias, the stuff people put in the wiki is exactly the set of things that are so hard to do it's worth having a reference for other people. The stuff in the postgres wiki is in no way representative of sql in general.

masklinn 4y ago

> But that's not a function of the language itself. It is tho, SQL is a declarative language, so the execution model is largely opaque, by language design. But even if it were solely an implementation detail, Closi would still be wrong: they literally stated that “it’s not any better” to try debugging a 100 lines python script than a 100 lines query. > As it is, you often have to take the whole damn thing apart from the inside to see what's going on, then put it all back together again. That's... suboptimal, to say the least. Which is the point? Sounds like you agree that it is significantly easier to debug a 100 lines python script than a 100 lines SQL query.

ltbarcly3 4y ago

DemocracyFTW2 4y ago

I often watch in horror what some people suggest is 'good SQL'. You even find plenty of those humongous multi-hundred-line beasts on the official PostgreSQL wiki, a single statement going over several pages if you were to print it out. Sure that's hard to debug. What I do in such cases is using many intermediate views, sometimes just named like `_foobar_010`, `_foobar_020` and so on, and a single `create (materialized) view foobar ... select from _foobar_120 ...`. That way, I can rely on the DB caring for basic structural soundness, giving error messages that are better localized than "something is wrong near ','", and I can visually (or, indeed, programmatically) debug all the intermediate steps.

ltbarcly3 4y ago
This is just obviously selection bias, the stuff people put in the wiki is exactly the set of things that are so hard to do it's worth having a reference for other people. The stuff in the postgres wiki is in no way representative of sql in general.