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

Feature Request: Line break before or after "+" #796

Open
gwduvalljr-AT opened this issue Nov 4, 2024 · 3 comments
Open

Feature Request: Line break before or after "+" #796

gwduvalljr-AT opened this issue Nov 4, 2024 · 3 comments
Labels

Comments

@gwduvalljr-AT
Copy link

Describe the Feature
When building a long string in a script for insert or update, I like to break it into logical chunks for readability and easy maintenance. Also, VSCode does not like really long single-line strings. Something like this:

declare @longString nvarchar(max) = '';

set
    @longString = @longString +
	'{"JsonObject": [{' +
	'"JsonField1": {"Name": "JsonValue1"},' +
	'"JsonField2": {"Name": "JsonValue2"},' +
	'"JsonField3": {"Name": "JsonValue3"},' +
	'"JsonField4": {"Name": "JsonValue4"}' + 
	'}]}';


update MyTable set MyColumn = @longString where...

At this time, when formatting with this extension, the formatter joins all these lines onto a single line.

Why do you want this feature?
I'd like to keep my strings readable and not have the issue with VSCode an long strings.

@nene
Copy link
Collaborator

nene commented Nov 4, 2024

It's a very reasonable feature request.

Unfortunately this is very unlikely to get implemented in SQL Formatter, because I'm not really doing any real feature development in this library. Rather I'm concentrating on prettier-plugin-sql-cst, which is much more likely to support such a thing in the future, as its architecture is much better suited for that.

@gwduvalljr-AT
Copy link
Author

gotcha

I checked out the prettier plugin. I use prettier every day. We are a SQL Server shop. Any idea when tsql will be supported?

@nene
Copy link
Collaborator

nene commented Nov 4, 2024

Hard to say. Currently the main priority is to get PostgreSQL supported. Then MySQL/MariaDB. Given that SQL Server is proprietary, it's also harder implement support for it. Like with PostgreSQL I have often dug into PostgreSQL source code to figure out which syntax exactly is supported. With SQL Server I've always found the documentation to be one of the most confusing among SQL dialects. So I'm personally not really keen on implementing a parser for it :(

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

No branches or pull requests

2 participants