By the end of this lesson you can tell keywords, identifiers and literals apart, use single and double quotes correctly, add comments, and lay out a query in a readable, conventional style.
Why it matters: Most beginner errors are grammar slips: a stray comma, the wrong quotes, a misspelled name. Knowing the rules lets you fix them in seconds, and a consistent style makes your queries easy for colleagues (and your future self) to review.
Dataset: Starter shop. Examples run in the editor on the right.
A SQL statement is built from clauses, and each clause starts with a keyword. In SELECT product_name FROM products; there are two clauses: the SELECT clause and the FROM clause. Clauses must come in a fixed order: SELECT before FROM, FROM before WHERE. The statement ends with a semicolon.
Inside a statement there are three kinds of word:
| kind | what it is | examples |
|---|---|---|
| keyword | a reserved word of the SQL language | SELECT, FROM, WHERE, AS |
| identifier | the name of something in the database | customers, customer_name |
| literal | a value written directly in the query | 7, 75.50, 'Riyadh' |
Case and spacing
Keywords are not case-sensitive: select, Select and SELECT are the same. PostgreSQL also folds unquoted identifiers to lower case, so Customer_Name and CUSTOMERS find customer_name and customers.
Spaces, tabs and line breaks are all just separators, and you can use as many as you like. The two queries below are identical to PostgreSQL; only one is pleasant to read.
select CUSTOMER_NAME,City from Customers;It runs: keywords and unquoted names are case-insensitive, and extra spaces don't matter. You get the name and city of all 12 customers, with the column headings in lower case, as they're stored.
SELECT customer_name,
city
FROM customers;Identical result. Keywords in capitals, names in lower case, one clause per line, and the column list aligned. When a query grows to twenty lines, this layout is what makes it reviewable.
Single quotes versus double quotes
This is the rule beginners trip on most often:
- Single quotes make a text literal, a value:
'Riyadh','delivered'. - Double quotes make an identifier, a name:
"customer_name". Inside double quotes the name is taken exactly as written, capitals included.
So SELECT 'city' FROM customers doesn't return cities. It returns the word city on every row, because 'city' is a value. And SELECT "City" FROM customers fails: there is no column spelled with a capital C. Normally you never need double quotes; write names plainly in lower case.
SELECT customer_name, 'city' AS what_is_this
FROM customers;The second column contains the text city on all 12 rows, not the customers' cities: the single quotes turned it into a fixed value. A literal is useful on purpose (for labels), but a disaster by accident.
Comments
A comment is text PostgreSQL ignores, written for humans. Use them to explain why a query does something.
--starts a comment that runs to the end of the line./* … */wraps a comment that can span several lines.
/* Weekly stock check for the warehouse team.
One row per product. */
SELECT product_name,
stock -- units on the shelf right now
FROM products;PostgreSQL skips both comments and returns the name and stock of all 10 products. A reviewer instantly knows what the query is for and what each column means.
Naming and layout conventions
Teams agree on a style; the most common one, used throughout SQL Quest, is:
- Keywords in UPPER CASE; table and column names in lower
snake_case(words joined by underscores). - Each main clause (
SELECT,FROM,WHERE,ORDER BY) starts a new line. - Long column lists get one column per line, indented under SELECT.
- Every statement ends with
;. When you run several statements in one go, the semicolons tell PostgreSQL where each one ends.
None of these change results. All of them reduce mistakes.
-- what this query answers
SELECT column_one,
column_two
FROM table_name
WHERE condition;