कीवर्ड केस विकल्प

Keyword case rewrites SQL keywords in uppercase (the default) or lowercase. This page lists exactly what is re-cased and what is left as you typed it, including a few words that behave differently from what you might expect.

What the option does

The formatter recognizes SQL keywords and writes every one of them in the chosen case, no matter how they were typed. Select, select and SELECT all become SELECT with the default setting and select with lowercase. Everything that is not a keyword keeps its original spelling, so the option never changes your table, column or alias names unless they are unqualified keywords themselves, a case covered in its own section below.

Possible values and default

The input below mixes cases on purpose. Compare the two outputs:

-- Active customers: keep this comment as written
Select id, Coalesce(nickname, first_name) as display_name, count(*) as logins, upper(email) as email_upper, Round(avg(session_minutes), 1) as avg_minutes
From customer_logins
Where is_active = TRUE and deleted_at Is Null and plan_code <> 'select from where'
Group By id, nickname, first_name, email

-- Active customers: keep this comment as written
SELECT id,
    COALESCE(
        nickname,
        first_name
    ) AS display_name,
    COUNT(*) AS logins,
    upper(email) AS email_upper,
    Round(
        AVG(session_minutes),
        1
    ) AS avg_minutes
FROM customer_logins
WHERE is_active = true
AND deleted_at IS NULL
AND plan_code <> 'select from where'
GROUP BY id,
    nickname,
    first_name,
    email

-- Active customers: keep this comment as written
select id,
    coalesce(
        nickname,
        first_name
    ) as display_name,
    count(*) as logins,
    upper(email) as email_upper,
    Round(
        avg(session_minutes),
        1
    ) as avg_minutes
from customer_logins
where is_active = true
and deleted_at is null
and plan_code <> 'select from where'
group by id,
    nickname,
    first_name,
    email

What is re-cased

• Clause and operator keywords: SELECT, FROM, WHERE, GROUP BY, AS, AND, IS, IN, JOIN, ON, NOT, EXISTS, LIKE, ILIKE and so on.
• DDL and upsert words: PRIMARY KEY, FOREIGN KEY, REFERENCES, CONSTRAINT, UNIQUE, CHECK, DEFAULT, INDEX, CASCADE, RESTRICT, TRUNCATE, TRIGGER, SEQUENCE, SCHEMA, and the ON CONFLICT … DO NOTHING words.
• Row limiting and window frames: FETCH FIRST/FETCH NEXT, ROWS ONLY, WITH TIES, RECURSIVE, ROWS, UNBOUNDED, PRECEDING, FOLLOWING and CURRENT ROW.
• NULL, which follows the setting like any other keyword: IS NULL or is null.
• Data type names such as INTEGER, TEXT or DATE, including after a PostgreSQL :: cast.
• Some function names: the aggregates COUNT, SUM, AVG, MIN and MAX, plus COALESCE, EXTRACT and CAST, are treated as keywords and follow the setting.
• Keywords inside PostgreSQL dollar-quoted bodies. Functions and DO blocks written between $$ markers are laid out as PL/pgSQL, and their BEGIN, IF, END IF and similar keywords are re-cased too. See the PostgreSQL formatting guide.

What is left as written

• String literals. In the example, 'select from where' is untouched in both outputs. Quoted text is data, and changing it would change the result of the query.
• Comments. Both -- and /* */ comments are copied as they are, even when they contain keywords.
• Most function names. Functions that are not in the list above, such as UPPER, ROUND, NOW, NULLIF and your own functions, keep whatever case you typed. In the example, upper(email) stays lowercase in the uppercase output and Round(...) keeps its capital R in both. If you want function names to be consistent, type them consistently.
• Quoted identifiers. Names in double quotes, MySQL backticks or SQL Server brackets, such as "Order Id", "select", `order` or [dbo].[orders], are copied exactly, even when the word inside is a keyword. A quoted name is case-sensitive in most databases, so re-casing it would point the query at a different object.
• Qualified names. Every part of a dotted name keeps its typed case: t.month stays t.month and Sales.Orders stays Sales.Orders.
• Table, column and alias names that are not keywords.

Identifiers that are keywords

For a bare name the formatter decides by the word, not by its role in the statement. An unquoted, unqualified name that is also a keyword is re-cased like a keyword, whether it is an alias or a column written without a table qualifier. The same word after a qualifier, as in p.month, or inside quotes, as in "month", is left alone. Words such as month, value, date and plan are on that list, even though many databases accept them as ordinary names:

select p.id, extract(month from p.paid_at) as month, p.amount as value, p.paid_at::date as date, p.status from payments p

SELECT p.id,
    EXTRACT(MONTH FROM p.paid_at) AS MONTH,
    p.amount AS VALUE,
    p.paid_at::DATE AS DATE,
    p.status
FROM payments p

select p.id,
    extract(month from p.paid_at) as month,
    p.amount as value,
    p.paid_at::date as date,
    p.status
from payments p

With lowercase keywords nothing visible happens. With uppercase, the aliases become MONTH, VALUE and DATE. In PostgreSQL, MySQL and Oracle, unquoted column names and aliases are case-insensitive, so the query runs the same. SQL Server follows the database collation: with a case-sensitive collation, a re-cased column name no longer matches the column, so qualify such a column (p.date) or quote it and it keeps its typed case. The result column label can also change: MySQL and SQL Server return an alias exactly as written, so a client that looks up columns by name in a case-sensitive way would see MONTH instead of month. PostgreSQL folds unquoted names to lowercase and Oracle to uppercase, so for them the label is the same either way.

The simplest way to avoid the question is to give aliases descriptive names that are not keywords: paid_month, amount_paid, paid_on. That is good practice anyway, because keyword names confuse people as well as tools.

Uppercase or lowercase

Uppercase keywords are the long-standing convention. Most database documentation uses them, and many team style guides recommend them because they separate the language from the names at a glance, even in plain text with no syntax highlighting: in an email, a log file or a terminal.

Lowercase has gained ground, especially in analytics and data engineering teams. The arguments are that every modern editor highlights keywords anyway, that lowercase is easier to type, and that a query in all caps looks louder than it needs to. If most of your SQL lives inside application code next to lowercase identifiers, lowercase can also look more at home.

Neither choice affects how the query runs. What matters is that one case is used everywhere, so that a diff never shows a line changed only because someone typed select instead of SELECT. Pick one in your style guide and let the formatter enforce it. The setting combines freely with the other options: indent spaces, maximum columns, comma placement and parentheses on new line.