Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FORMATTING] DEFAULT VALUES not properly supported in INSERT statement #718

Closed
jonatanschroeder opened this issue Feb 16, 2024 · 3 comments · Fixed by #720
Closed

[FORMATTING] DEFAULT VALUES not properly supported in INSERT statement #718

jonatanschroeder opened this issue Feb 16, 2024 · 3 comments · Fixed by #720
Labels

Comments

@jonatanschroeder
Copy link

Input data

Which SQL and options did you provide as input?

INSERT INTO workspaces DEFAULT VALUES RETURNING id;

options:

{ language: 'postgresql', paramTypes: { named: ['$'] } }

Expected Output

The main issue is that DEFAULT VALUES should be treated as a unit, as it is distinct from the usual VALUES or the query that typically follows INSERT INTO.

INSERT INTO
  workspaces
DEFAULT VALUES
RETURNING
  id;

Actual Output

INSERT INTO
  workspaces DEFAULT
VALUES
RETURNING
  id;

Usage

  • How are you calling / using the library?
  • What SQL language(s) does this apply to?
    • This is specifically for Postgres.
  • Which SQL Formatter version are you using?
    • 15.2.0
@nene
Copy link
Collaborator

nene commented Feb 17, 2024

Thanks for reporting.

This can probably be patched in sql-formatter. Though there are many scenarios like that where it fails.

If you want a Prettier plugin to format PostgreSQL, I suggest you try prettier-plugin-sql-cst. It does not yet support full PostgreSQL syntax, but it should work for most of the common scenarios (this issue tracks the current progress of PostgreSQL support) and it does an overall better job at formatting than SQL Formatter will ever be capable of.

@jonatanschroeder
Copy link
Author

Thanks for the quick reply.

About the Prettier plugin, I just did a quick check, and it seems to work well in most cases, but there are some cases that it does not support which we use in our case, such as types (CREATE TYPE), DO code statements, FULL JOIN, and a few minor constructs. Also, the fact that it's in experimental stage means it's probably a good idea for us to stick with the custom plugin package has been working for us for the last 12 months until this package is in a more stable setting. That said, it looks promising, and it's likely something to consider in a future release. Also, some of the formatting choices in that plugin seem to me (personally) to make a bit more sense than the ones used in sql-formatter.

@nene
Copy link
Collaborator

nene commented Feb 20, 2024

Thanks for the feedback. Always good to learn which actual features, that people are using, are missing. I can then possibly prioritize these before others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants