sql-formatter-org / sql-formatter

A whitespace formatter for different query languages
https://sql-formatter-org.github.io/sql-formatter/
MIT License
2.31k stars 398 forks source link

[FORMATTING] Empty lines between comment lines/blocks should be preserved #772

Open regexident opened 2 weeks ago

regexident commented 2 weeks ago

Input data

Which SQL and options did you provide as input?

I'm using the default settings of "Prettier SQL VSCode".

sql-formatter strips empty lines between line/block comment sections, fusing the sections together, which is highly undesirable if those comment sections are unrelated and just happen to not have any code in between them.

This behavior is particularly unfortunate for code that makes use of minimap section header comments like this:

-- MARK: Section name

/* MARK: Section name */

… which get dissolved into whatever other comments happen to surround it, despite being clearly a separate "thing".

At the very least I would expect sql-formatter to expose a configuration option for preserving gaps between comment blocks.

-- MARK: Tables

-- Some free-standing comment block providing some
-- more broad discussion on the code surrounding it
-- without being attached to a specific code

-- Some comment describing the `foo` view
--
-- With maybe even a block and some more details
-- about the why, the what, and the how.
CREATE TABLE IF NOT EXISTS maybe_foo (/* ... */);

/* MARK: Views */

/*
 Some free-standing comment block providing some
 more broad discussion on the code surrounding it
 without being attached to a specific code
 */

/*
 Some comment describing the `foo` view

 With maybe even a block and some more details
 about the why, the what, and the how.
 */
CREATE VIEW IF NOT EXISTS foo AS
SELECT /* ... */ FROM maybe_foo
WHERE NOT is_deleted;

Expected Output

-- MARK: Tables

-- Some free-standing comment block providing some
-- more broad discussion on the code surrounding it
-- without being attached to a specific code

-- Some comment describing the `foo` view
--
-- With maybe even a block and some more details
-- about the why, the what, and the how.
CREATE TABLE
    IF NOT EXISTS maybe_foo (/* ... */);

/* MARK: Views */

/*
Some free-standing comment block providing some
more broad discussion on the code surrounding it
without being attached to a specific code
 */

/*
Some comment describing the `foo` view

With maybe even a block and some more details
about the why, the what, and the how.
 */
CREATE VIEW
    IF NOT EXISTS foo AS
SELECT
    /* ... */
FROM
    maybe_foo
WHERE
    NOT is_deleted;

Actual Output

-- MARK: Tables
-- Some free-standing comment block providing some
-- more broad discussion on the code surrounding it
-- without being attached to a specific code
-- Some comment describing the `foo` view
--
-- With maybe even a block and some more details
-- about the why, the what, and the how.
CREATE TABLE
    IF NOT EXISTS maybe_foo (/* ... */);

/* MARK: Views */
/*
Some free-standing comment block providing some
more broad discussion on the code surrounding it
without being attached to a specific code
 */
/*
Some comment describing the `foo` view

With maybe even a block and some more details
about the why, the what, and the how.
 */
CREATE VIEW
    IF NOT EXISTS foo AS
SELECT
    /* ... */
FROM
    maybe_foo
WHERE
    NOT is_deleted;

Usage

In VSCode via the inferrinizzard.prettier-sql-vscode extension.

I'm using PGSQL, but it should apply to all supported dialects, I presume.

Whatever version shipped with Prettier SQL VSCode v1.6.0.

nene commented 2 weeks ago

Thanks for the suggestion. This is definitely an area where SQL Formatter lacks (among many things).

However, even when this feature gets implemented in SQL Formatter, it will likely never reach the plugin you're using, because it's no longer maintained. See the FAQ

This particular problem has been solved in prettier-plugin-sql-cst. Which is another SQL formatting tool I've written to overcome the fundamental shortcomings of SQL Formatter. It doesn't yet have full PostgreSQL support, but perhaps enough for your use.

Regarding implementing this in SQL Formatter.. well, I'm not really doing any new feature development in here. So the chances of it happening are pretty low.