[psteinroe]

Stacked on #896.

Three places where a call-like expression broke in the wrong place or not at all.

count(*) filter (...) keeps count(*) together

A function call put its name and arguments in the same group as a following FILTER or WITHIN GROUP. When that clause didn't fit, the arguments broke too:

-- before
count(
  dl.id
)
filter (where
  dl.created_at > now() - cast('180 days' as interval))
-- after
count(dl.id)
  filter (where
    dl.created_at > now() - cast('180 days' as interval))

The name and arguments now have their own group whenever FILTER, WITHIN GROUP or OVER follows. OVER already had one. The line breaks before the clause first. A clause that moves to its own line is indented one level, so it reads as part of the call: percentile_cont(0.5)\n within group (order by x).

A FILTER clause that fits stays on one line

filter (where was followed by a soft line in the call's group, so a FILTER that fit still broke as filter (where\n cond) once the call broke, with ) attached to the condition. FILTER is now a group of its own: filter (where cond) when it fits, and otherwise filter (, where cond indented on its own lines, and ) on its own line, like a policy's using (...).

Long array[...] literals fill indented lines

array[...] had no indent and no break after [. Once it didn't fit, every element after the first went on its own line at the enclosing indent, and ] stuck to the last element:

-- before
oid <> all (cast(array['regproc',
'regprocedure',
'regoper',
...
'regcollation']
as regtype[]))
-- after
oid <> all (cast(array[
  'regproc', 'regprocedure', 'regoper', 'regoperator', 'regconfig',
  'regdictionary', 'regnamespace', 'regcollation'
]
as regtype[]))

Arrays now use the same layout as an IN (...) list. On one line when they fit; otherwise a break after [, the elements filling indented lines, and ] back on the line the array started on.

json_value, json_query and json_exists respect the line width

These had no indent and no break after (, so a long context item ran past the width, and the clauses that wrapped did so at the enclosing indent with ) attached to the last one. #882 left this out of scope. They now use the function-call layout that json_table already uses: on one line when the call fits, otherwise the context item, the path and each clause (passing, returning, wrapper, quotes, on empty, on error) on their own lines, one level in, and ) on its own line:

-- before (lineWidth 60)
select
  json_value(jsonb_column_with_long_name, '$.some.very.long.path.expression.here'
  returning int
  default 0 on empty
  error on error)
from
  t;
-- after
select
  json_value(
    jsonb_column_with_long_name,
    '$.some.very.long.path.expression.here'
    returning int
    default 0 on empty
    error on error
  )
from
  t;

The passing arguments are a group of their own, so passing 0 as x, 2 as y stays on one line. The three functions shared most of their emitter code, which is now written once.

Snapshot changes

All reviewed:

• fn(\n arg\n)\nfilter (where ... / within group (...) → fn(arg) with the clause indented on the next line (aggregates, ordered_set_filter, tuplesort, func_call_within_group_filter_0, 20230405163940_download_metrics, window)
• array elements one per line at the enclosing indent → filled, indented lines between array[ and ] (amutils, arrays, type_sanity, stats_ext, rowtypes, rangefuncs, multirangetypes, jsonpath)
• broken json_value/json_query/json_exists calls → function-call layout (sqljson_queryfuncs, most of the diff, and json_returning)

New function_call_layout.rs tests cover count(*) filter, within group, long and short arrays, and the three JSON functions, broken and flat.

Not covered

• json_arrayagg/json_objectagg, xmlserialize/xmlexists, position(... in ...), extract(... from ...) and a few statement headers listed in the release review can still go past the width.

Follow-ups: The remaining width offenders are fixed in #946.