darold / darold/pgFormatter

Bad indentation with subquery inside nested paratheses

Open
#391 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PLpgSQL
Stars
2k
Forks
121
Avg merge
4d 21h
Merged PRs (30d)
7

Description

The following query:

SELECT
    *
FROM
    some_table
WHERE
    AND (row2 = 'b'
        OR row3 = 'c'
        OR EXISTS (
            SELECT
                1
            FROM
                some_table
            WHERE
                row4 = 'd')
        OR (row4 = 'e'));

Gets formatted by pgFormatter 8d0290b0af21054bdb21ea6d83bf4447a8013bfe as:

SELECT
    *
FROM
    some_table
WHERE
    row1 = 'a'
    AND (row2 = 'b'
        OR row3 = 'c'
        OR EXISTS (
            SELECT
                1
            FROM
                some_table
            WHERE
                row4 = 'd')
            OR (row4 = 'e'));

The final OR (row4 = 'e') gets indented one level further to the right than OR row3 = 'c', even though they are part of the same disjunction.

If the OR EXISTS (SELECT 1 FROM some_table WHERE row4 = 'd') part of the query gets deleted, OR (row4 = 'e') gets moved back one indentation level.

This bug only occurs if the disjunction is inside a parenthesis. If the parenthesis is removed, the indentation works as expected.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by formatting the supplied nested-parenthesis query with pgFormatter and compare it with the expected output. Trace how the formatter handles the OR EXISTS subquery and the following OR expression; done means the final OR (row4 = 'e') aligns with the other disjunction terms without the subquery being removed.

Written by the indexing model from the issue text.

Assessment

Tech stack
postgresql, sql
Domain
databases, tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.