fix: handle postgres pgvector table layout

[mtibben]

PostgreSQL pgvector table formatting should preserve the expected layout for CREATE TABLE statements that combine extension-style vector columns, array types, table constraints, and partition clauses.

The current Postgres formatting path treats pgvector-style vector(...) and adjacent bracketed syntax too broadly, so reflow inserts spaces into PostgreSQL type/reference syntax and removes expected continuation indentation from table constraints. This change gives the parser and reflow config more precise segment types for these constructs so vector(1536), TEXT[], and REFERENCES table(column) keep their PostgreSQL shape while table bodies retain their indentation.

Closes #2747

[mikills]

Verified locally. The pgvector/Postgres fix looks good, but I think this needs one change before merge.

The new global config:
[sqruff:layout:type:start_square_bracket]
spacing_before = touch:inline

regresses array literals outside Postgres. For example, on this PR:

SELECT [1, 2, 3] AS arr

is fixed to:

SELECT[1, 2, 3] AS arr

for BigQuery, SparkSQL, and DuckDB. On main, those preserve the space.

Could we scope the TEXT[] behavior to the Postgres array datatype suffix instead of changing start_square_bracket
globally? A regression fixture for array literal spacing would be useful too.

The rest looks solid: vector(1536), TEXT[], and REFERENCES table(col) are handled much better.

[mtibben]

Thanks for catching this. I agreed that the start_square_bracket layout change was too broad, so I removed the global spacing rule and scoped the touch-before behavior to a new Postgres array_type_suffix segment instead.

I also added regression coverage for SELECT [1, 2, 3] AS arr under BigQuery, SparkSQL, and DuckDB, and kept the pgvector/Postgres fixture covering TEXT[], vector(1536), and REFERENCES table(col).

[benfdking]

This is already partially solved with the correct config as well. Did we consider that?

https://playground.quary.dev/?secondary=Cst#eNptUdFqwkAQ/JUlTwq+lNI+WPpwxlWOphe5XKFiJKg5gzReYu4shdJ/78ZEbYP3uDNzOzvz7dlD7g09XyJTCPiuUEQ8FMAnIEJFAx6pCD71xhXVU2xi0zIVGwXYYemv1b7MdaL3a52mO5NZ6MUG6O1SGPFphJKz4KQQb0EwaDBbHKuNThoKF4T9xzeFcdo4UGSui102tQ57dw/3j/0WzFdrnduTbrFsZzPJX5mcwwvOoXfZPCCDZ5UfikhJVhvZfiTnkxpqw6jfJJTIp6LzT/9KkDhBicLHaywNzd6kU+JjDJCC9VnkszHGpg8zJhVXdRujOQQU8d9VVIY38Kx2rg6aKlzYQ3XcbpexSXernOKAZygL67JK27q4Fh+26PCMkaDMEldlexK46khXllkT52Xg/fwCjKStsg== the right conig

Looking at your query, though, I think there are still some improvements that we should make. It might be worth just breaking them up a little.

[mtibben]

This is already partially solved with the correct config as well. Did we consider that?

Looking at your query, though, I think there are still some improvements that we should make. It might be worth just breaking them up a little.

Ah I see - with [sqruff:dialect:postgres] pgvector = true, the pgvector datatype parsing side is already covered, so this PR is bundling that config-dependent behavior with a few separate layout issues.

I’ve split the remaining formatter changes into smaller draft PRs:

• fix: scope postgres array suffix spacing #2780: Postgres array datatype suffix spacing, e.g. text[], while avoiding changes to array literal spacing in other dialects.
• fix: preserve postgres reference column list spacing #2781: Postgres referenced column list spacing, e.g. REFERENCES parent(id).
• fix: preserve postgres named constraint indentation #2782: Named Postgres table constraint body indentation after CONSTRAINT name.

I think we can treat this PR as superseded by those smaller PRs and review whichever fixes still make sense independently.