'최대 열 수' 옵션
Maximum columns is the longest line the formatter will leave in its output. This page explains exactly how long lines are wrapped, what the option deliberately does not do, and how to choose a width, including 0 to switch wrapping off.
What the option does
Formatting happens in two stages. First the query is laid out: one clause per line, one select item per line, joins and conditions on their own lines, subqueries indented. Then, as a final pass, every output line is measured. A line that fits within the limit is left alone. A line that is longer is cut at the last space that keeps the first part within the limit, and the rest continues on a new line indented 2 spaces deeper than the line it came from. If the continuation is still too long, the same cut is repeated on it.
In practice, the long lines are almost always computed select items and WHERE conditions with long
expressions. Short queries are not affected at all.
Possible values and default
| Value | Result |
|---|---|
120 (default) | Lines longer than 120 characters are wrapped. |
| Any other number up to 9999 | Lines longer than that number are wrapped. A line of exactly that length is kept. |
0 | Wrapping is disabled. Lines are as long as the layout makes them. |
The same query at several widths
The query below has one long computed column and one long condition. With the default of 120, only the select item is too long (131 characters), so just its alias moves to a continuation line. At 60, both the expression and the condition wrap.
select order_id, base_amount + freight_amount + insurance_amount + handling_fee - store_credit - gift_card_amount - promo_discount as amount_due from order_lines where base_amount + freight_amount + insurance_amount > minimum_order_value + regional_surchargeSELECT order_id,
base_amount + freight_amount + insurance_amount + handling_fee - store_credit - gift_card_amount - promo_discount
AS amount_due
FROM order_lines
WHERE base_amount + freight_amount + insurance_amount > minimum_order_value + regional_surchargeSELECT order_id,
base_amount + freight_amount + insurance_amount +
handling_fee - store_credit - gift_card_amount -
promo_discount AS amount_due
FROM order_lines
WHERE base_amount + freight_amount + insurance_amount >
minimum_order_value + regional_surchargeAt 40 the same rule simply runs more times. Notice that every continuation line is exactly 2 spaces deeper than its first line: 6 spaces for the select item, which starts at 4, and 2 spaces for the condition, which starts at column 0.
SELECT order_id,
base_amount + freight_amount +
insurance_amount + handling_fee -
store_credit - gift_card_amount -
promo_discount AS amount_due
FROM order_lines
WHERE base_amount + freight_amount +
insurance_amount >
minimum_order_value +
regional_surchargeWith 0 nothing is wrapped. The select item stays on a single 131-character line and the condition on a 96-character line:
SELECT order_id,
base_amount + freight_amount + insurance_amount + handling_fee - store_credit - gift_card_amount - promo_discount AS amount_due
FROM order_lines
WHERE base_amount + freight_amount + insurance_amount > minimum_order_value + regional_surchargeWhat it does not do
Because wrapping is a final text pass and not part of the layout, a few things are worth knowing:
- It does not re-layout clauses. A wide limit never pulls select items back onto one line, and a narrow limit never moves a whole condition or join somewhere else. The clause structure is identical at every width; compare the 0 and 120 outputs above.
- It does not look for a logical break point. The cut goes at the last space that fits,
which may fall between an operator and its operand or between
ASand the alias, as the 120 example shows. It does not prefer breaking before a+or after a comma. When the last space that fits happens to follow a comma, the comma stays at the end of the first line, as inNUMERIC(18,followed by4)on the continuation line. - It never cuts inside quoted text or comments. String literals, quoted identifiers and
--or/* */comments are kept whole, and comment text never ends up on a line where it would be read as SQL. A line that is long only because of a long literal or comment may stay over the limit. - It never splits a word. An identifier longer than the limit is moved to a line of its own and left over the limit.
- It does not join lines. Raising the limit never merges lines that the layout keeps separate.
So treat the option as a safety net that keeps lines within your screen or review tool, not as a way to design the shape of a query. If an expression wraps three times at your chosen width, the readable fix is usually in the SQL: move the calculation into a CTE or a derived column with a clear alias, as shown in formatting complex queries.
Choosing a width
- 120 (default). Fits a typical editor window with a sidebar open and matches the line limit many teams already use for application code. Most well-structured queries never reach it.
- 80 to 100. Useful when SQL is reviewed in side-by-side diffs, read in a terminal, or pasted into documentation and tickets with a fixed width. Expect more wrapped expressions.
- Below 60. Rarely helpful. Deeply indented lines leave very little room, the output becomes a column of fragments, and at very small widths some lines simply cannot be cut short enough and stay over the limit.
- 0. Use it when the output must not contain any line break the layout did not create, for example when you compare formatted queries in a tool that soft-wraps on its own, or when generated SQL is stored and diffed by a machine rather than read by people.
Remember that indentation counts toward the width. With indent spaces set to 4, a line inside a subquery that is two levels deep already starts at column 8, so it wraps sooner than the same text at the top level. Lowering the indent to 2 is often a better fix for deeply nested queries than raising the limit.
Tips for code review
The width you choose affects diffs as much as readability. Lines that wrap move when an identifier changes length: renaming one column can shift the cut point and touch the continuation line too. If your team reviews SQL in pull requests, choose a width once, record it alongside your other code review conventions, and keep long calculations short enough that they do not wrap at all. The other options, comma placement and keyword case, do not change line lengths in a way that matters here.