Postgres Support

[shishkin]

I'm looking forward to this project to support Postgres dialect, so it can unblock Postgres support in the prettier plugin.

Edit: I'm hijacking this issue to track the overall progress of PostgreSQL support:

• [ ] #42
  • Mostly done, some quirky edge-cases remaining, like allowing some reserved keywords as implicit aliases.
• [ ] #49
  • Mostly done, some quirky edge-cases remaining, like full support for custom operators and the elaborate type casting syntax.
• [x] #46
• [x] #44
• [x] #47
• [x] #48
• [x] #57
• [x] #58
• [x] #63
• [x] #64
• [ ] #65
  • Most of the commonly used syntax supported.
• [x] #66
• [ ] #67
  • Nothing yet.
• [ ] #73
  • Nothing yet.
• [ ] #78
  • Nothing yet.
• [ ] #43
  • I have barely started even mapping out the work that remains.

[karlhorky]

Would also love to see PostgreSQL support here 🙌 @nene is this something on the mid-term roadmap?

[nene]

Well, it is sort of on the roadmap since starting working on this whole library. But Postgres being pretty big and complex, just the thought of the task ahead puts me off from starting to implement support for it.

[karlhorky]

Understood, thanks for the reply. Really appreciate the work that you're doing on both this project and sql-formatter.

I guess there's also not a way to build on existing parsers / existing schema data or use code generation somehow to reduce the implementation complexity here... 🤔

[wolfgangwalther]

To fully support postgres, it would be good to support psql meta commands (starting with \) and variables (with :), too.

[nene]

To fully support postgres, it would be good to support psql meta commands (starting with ) and variables (with :), too.

Yep. This is in the plans. But for now I'm concentrating on finishing the support for the actual SQL part.

Another thing to fully support Postgres is having support for PL/pgSQL.

I think both can be implemented as supersets of the base PostgreSQL grammar.