51–60 of 95 posts
Earlier quoted context omitted.
I hate you and and the awful layout you have just introduced me to... Also, that is how I will be formatting all my SQL from now on.
alt styling SELECT a, b, COUNT(*) as count FROM table WHERE cond1 AND cond2 GROUP BY a, b ORDER BY count DESC
I wanted to use this linter, but they don't support many things that are used in real production code. By example, a simple postgres function like this one can't be parsed: CREATE OR REPLACE FUNCTION public.setof_test() RETURNS SETOF text LANGUAGE sql STABLE STRICT AS $function$ select unnest(array['hi', 'test']) $function$ ;
Earlier quoted context omitted.
I guess it depends on what you want out of a linter e.g. if you want it to check just syntax or semantics as well. Is “= NULL” syntactically correct?
The compiler checks syntax - if that’s all a linter did it wouldn’t be very useful.
Earlier quoted context omitted.
The reason that those people care about formatting is that it matters when the code is used to communicate with other people, not just with machines. Having a consistent style within the team, means the team can communicate more easily - even if the net effect for an individual working on a codebase alone is minimal.
Yes but realistically, save for the code that someone who's really inexperienced or sloppy would write, fixating over whether someone is writing select a, b, c from foo where bar = 'quux' rather than SELECT a, b, c FROM foo WHERE bar = 'quux' is petty and immaterial to what the code communicates. Worse if it's about details within the roughly the same style. Edit: but if there's a code formatter that can be seamlessl…
Earlier quoted context omitted.
I hate you and and the awful layout you have just introduced me to... Also, that is how I will be formatting all my SQL from now on.
alt styling SELECT a, b, COUNT(*) as count FROM table WHERE cond1 AND cond2 GROUP BY a, b ORDER BY count DESC
- why capitalize KEYWORDS. We're no longer in 1970s. We use colors
- why waste so much space. Why not just put table on the same line with from. With joins this just bloats up
- for complicated conditions they have to be put on their own lines. Do I give each AND a separate line and waste ever more space?I wanted to use this linter, but they don't support many things that are used in real production code. By example, a simple postgres function like this one can't be parsed: CREATE OR REPLACE FUNCTION public.setof_test() RETURNS SETOF text LANGUAGE sql STABLE STRICT AS $function$ select unnest(array['hi', 'test']) $function$ ;
Added this here: https://github.com/sqlfluff/sqlfluff/pull/1522
Demonstrating how easy it is to add this sort of thing to the project thanks to how the code is structured! :-)
Earlier quoted context omitted.
The compiler checks syntax - if that’s all a linter did it wouldn’t be very useful.
`= NULL` is perfectly legal syntax - but it isn't doing what you think it is.
Earlier quoted context omitted.
I've seen it a lot in Data Science/Analytics environments, as it allows for faster query iterations than trailing commas.
Yes you can find sources advocating for leading commas and it's commonly used. I have "Google BigQuery: The Definitive Guide" on my desktop, it was written by senior Google employees involved in the steering and use of the product inside, for what it's worth, and it advocates for leading comma and SHOUTING THE KEYWORDS. I personally disobey both recommendations (I mean, the book is worth it for other reasons) but bot…
I wondered how much good you could do with an SQL linter that didn't have any access to the underlying schema, and the answer seems to be "mostly whitespace and capitalization issues".
Sqlfluff seems to ship with 48 "built-in" rules and opinions on spacing and capitalization. If it catches on, I think the larger community will mostly benefit after other companies "doing work" with it release their own collection of rules.
There surely is a need for a sql linter, but if it wants to be strict about syntax style, it should better familiarize itself with not-noob styles first. Eg. some people like to align the clauses vertically and use a leading, not trailing, comma. select a , b , count(*) as count from table where cond1 and cond2 group by a, b order by count desc
Yes! I write SQL this way. I grant the comma thing is more a matter of taste, but aligning clauses vertically and maximizing rivers is super useful to me and it forever mystifies me that it isn't standard. This is an extreme example, but I like to keep join clauses vertically aligned as well: select a , b , count(*) as count from table join table2 on table.key1 = table2.key1 and table.key2 = table2.key2 and DATEADD('…
select a
, b
, count(*) as count
from table
join table2
on table.key1 = table2.key1
and table.key2 = table2.key2
and DATEADD('day, 1, table.key3) = table2.key3
where cond1
and cond2
group by a, b
order by count desc