You really shouldn't act so condescending when you clearly don't even have a solid understanding of the basics yourself. That's a perfectly reasonable query that would run in less than a millisecond on a large database as long as it's been indexed correctly. There's nothing sloppy about it at all.
It's how a naive implementation would work. Nobody actually knows "how" this left join works since we don't know what the query planner will do. Manifesting a whole outer join is not totally unreasonable in all cases.
I think you come off as very aggressive and there's no need for that tone.
But I do agree with the sentiment that the query might not be bad.
The where clause at the end will filter to the desired rows. The left join will do absolutely nothing bad.
The purpose of the left join is to include voters who might not be assigned to a precinct.
It's a perfectly fine and performant query.
Outputting the query also doesn't really make any difference. Despite what the people on Twitter are saying showing the query does not make SQL injection easier or harder, it's irrelevant.
The big problem with the query is the lack of bound parameters. It's possible to do that safely in theory, but in practice it's not a good idea.
No, we don't. Is there an index join between any of the tables? Is there an index on the name in some fashion and/or on the zip code. All we know is that this query can _probably_ not be answered by index only. What's the relative sizes of the tables (even that's not entirely clear)? Are any tables clustered by the filter criteria?
You wouldn't know and if you think you do, you should read up on possible access plans in modern database systems.
So an index on the join is completely irrelevant.
There are also under a million voters. Even with no indexes at all this query will perform just fine.
Because of the where and the left join there's pretty much just one possible access plan.
Criticize the lack of bound parameters and other problems if you like, but the query itself is perfectly fine.