Supabase likely has already discussed these things internally, but figured I would throw my opinion into the wind and see what others think, as this is a topic that I have spent a lot of time thinking about and playing around with.

Autoformatting Configuration

I am a big believer in highly opinionated syntax formatting, a lablack,gofmt,Prettier, etc

This helps users (even if they don't know it) by reducing bikeshedding possibilities and enforcing consistent style, and it helps the autoformatter developers by not having to support a exponential computational configuration explosion.

Some would argue that with how much history SQL has that an opinionated formatter would not be popular because there is so much history and differing opinion on how to format things, but I think that the explosion in popularity ofblack andprettier have proven that argument to be invalid; people are desperate to not have to think about where to put the newlines.

(I am not saying there should be zero config available, just that we should be very aggressive about limiting them. An obvious config option would be line length.)

Idempotency and Determinism

It is very important that the autoformatting is both idempotent and deterministic (perhaps with a fewintentional and documented exceptions)

Basically, any syntax that is interpreted to the same AST should result in the same syntax output (assuming the same config).

Canonical DDL Format

Postgres (kind of?) already does this for DDL:pg_dump (I believe) has a deterministic formatted output for DDL. Do we want our autoformatter to be the same format as that? I don't think that should be a goalunless we can somehow extract whatever library/module does it (like we do withlibpg_query) and use that. Honestly even if we could it probably still isn't a great idea, as I assume it was not designed for this purpose, and likely it only supports DDL.

Scope

What is the scope of the autoformatter? This is where other formatters fall short.

• DML: SELECT, INSERT, UPDATE, and DELETE will obviously be supported 😅, but what about:
  • CTEs
  • Window Functions
  • JSON Operations
  • Arrays
  • Composite types
  • Joins (including lateral joins)
  • RETURNING
• DDL: might seem obvious, but DDL in Postgres is a lot.
  • Views
  • FDW
  • Stored procs
  • Functions
  • Custom types
  • Inheritance
  • extensions
  • Schemas
  • Permissions
  • Triggers
  • Temp and unlogged tables
  • Partitioning
  • Tablespaces
  • Collations
• PL/pgSQL: Doeslibpg_query support PL/pgSQL?

What Format?

(I am assuming here that we agree with my above section)

Keyword Case

SELECT*FROM table;

vs

select*from table;

This honestly may be appropriate as a config, as I think people care a lot about which is used, and it (seems) trivial to support both.

Comma Placement

SQL (including Postgres flavored SQL) is notorious for lacking DX niceties such as trailing commas (pls Tom). (very related to the "New Lines" section below)

select a    , b    ,count(*)as countfrom table;

vs

select     a,    b,count(*)as countfrom table;

New Lines

When do we break a list/clause into multiple lines? This might be an instance where we take into consideration existing formatting, but this is very tricky. Seeblack magic trailing comma.

The obvious case where we have a newline is when we hit the max line length.

Indentation

2 characters? 4 characters? try to vertically align things (please god no)? Indentation characters might be a reasonable config option..