Competitor watch: valid SQL, red squiggles

This is the daily competitor watch. I take a batch of open issues from other SQL clients' public trackers, check whether SQLly has the same problem, and fix it if it does. The people who reported these did the hard part, so every one of them is named and linked below. Today's batch is about newer SQL syntax: PostgreSQL 16 and 17 features, SQL/JSON functions, PIVOT, a MariaDB keyword, and a window frame that apparently made a query stop running altogether.

SQLly's as-you-type check takes a different approach from most editors: it looks up table and column names against your database and stays quiet about grammar it doesn't model, instead of guessing. So most of these could not happen here. But being quiet about grammar is not the same as being right about names, and that is where both of today's bugs were. Ages are as of October 21, 2026. "Vendor" means someone the tracker marks as a member, collaborator or staff, or who speaks for the product's team in the thread.

The twelve issues

Eight of today's twelve are DataGrip's, and in fairness to JetBrains, six of them were moved to "Fixed in Branch" on September 2. So the fix exists somewhere; it just hasn't reached the people in these threads yet, some of whom have been waiting since 2023.

Support Redshift PIVOT and UNPIVOT syntax DataGrip DBE-16320

Age: opened 4 years, 1 month ago (September 2, 2022). No vendor reply, ever. Still "Submitted".

Votes / comments: 5 / 1.

The vibe: a careful report straight from the Redshift documentation's own examples, with the exact errors ('(' unexpected, 'FOR' unexpected). One person came by two months later to say "I have the same problem", and then the thread went quiet for four years. It is old enough to have started school.

Credit: Bryan M (bryanam) reported it; Yaseen Esmaeelpour (yaseen.esmaeelpour) confirmed it.

SQLly: SQLly doesn't connect to Redshift, but SQL Server and Oracle have the same PIVOT and UNPIVOT syntax, so we tried it there, and we had a version of this bug. A query that filtered on a pivoted column (WHERE val > 1 after an UNPIVOT) got a "column not found on any table" warning, because SQLly checked the name against the table underneath. While we were in there we found the same false warning for columns from CROSS APPLY, OUTER APPLY and SQL Server's OPENJSON … WITH (…), and for an unaliased subquery in FROM on PostgreSQL 16. All fixed: those sources are now treated like derived tables, and a mistyped column in an ordinary query is still caught. On Oracle, a pivoted result is now read-only in the grid, since its rows are not rows of the table underneath. (commit a8a2906a)

Support database function 'JSON_TABLE' DataGrip DBE-23448

Age: opened 1 year, 8 months ago (January 29, 2025). Last vendor reply 17 months ago, asking whether it still happens on the latest version. It did. Still "Submitted".

Votes / comments: 5 / 8.

The vibe: the most frustrated thread of the day. JSON_TABLE turns the whole query red, and the errors cascade from there. The reporter answered the "please update and check again" request with screenshots the next day; others kept confirming it on each new release. By August one commenter had 500 syntax errors in a medium-sized project and noted, politely, that they had been waiting a bit too long.

Credit: Serge Nazin (soberich) reported it and followed up with screenshots; Przemyslaw Sztoch (psztoch) pointed out that JSON_VALUE and JSON_QUERY have the same problem and later counted the 500 errors; Joshua Taylor (joshtau) and Abdelfattah Radwan (winterbolt) confirmed it on DataGrip 2025.2.

SQLly: we checked, and SQLly doesn't have this problem. The reporter's query, with its xpath casts and five-column JSON_TABLE, validates clean on PostgreSQL, and so does a JSON_TABLE on MySQL, including JSON_TABLE columns used bare in WHERE. Looking at this one is how we found the OPENJSON warning above. (changelog)

MULTIRANGE_TYPE_NAME not recognized when a custom PostgreSQL range type is created DataGrip DBE-19512

Age: opened 2 years, 10 months ago (December 11, 2023). Vendor reproduced it two days later; marked "Fixed in Branch" on September 2, 2026.

Votes / comments: 0 / 2.

The vibe: two problems in one: the option is flagged red, and the new range type shows up as a function. The vendor confirmed both within two days. Then two years passed, and in January a second person dropped by to say it was still there, as one does.

Credit: Illia Volochii (illia-v) reported it; Jouni Airaksinen (jouniii) confirmed it in January 2026.

SQLly: we checked, and SQLly doesn't have this problem. Both CREATE TYPE … AS RANGE statements validate clean, and when SQLly reads them from a SQL file they come out as types, not functions. (changelog)

Postgres syntax not parsed correctly for CREATE PUBLICATION DataGrip DBE-19638

Age: opened 2 years, 9 months ago (December 27, 2023). Vendor reproduced it the next day and wrote "still an issue in 2025.3" a year ago; marked "Fixed in Branch" on September 2, 2026.

Votes / comments: 0 / 2.

The vibe: one line of valid PostgreSQL 15 syntax and one error message, ALL or TABLE expected, got 'TABLES'. The vendor's own follow-up, 22 months later, reads like a note left on the fridge.

Credit: Jeff Barnes (jefbarn) reported it.

SQLly: we checked, and SQLly doesn't have this problem. CREATE PUBLICATION … FOR TABLES IN SCHEMA validates clean. (changelog)

PostgreSQL: 'STORAGE' parameter not recognized in CREATE TABLE DataGrip DBE-26419

Age: opened 1 year, 9 months ago (January 3, 2025). The only reply was an automated one, three months in, asking the reporter to upgrade; marked "Fixed in Branch" on September 2, 2026.

Votes / comments: 0 / 1.

The vibe: PostgreSQL 16 added a column option, and the editor responded with a list of the six things it would have accepted instead. The only response for over a year was a bot explaining that the team was under a high workload, which we believe.

Credit: Josha Inglis (Josha.Inglis) reported it.

SQLly: we checked, and SQLly doesn't have this problem. bar TEXT STORAGE EXTENDED validates clean, and the column keeps its name when SQLly reads the table definition from a file. (changelog)

AT LOCAL of Postgres dialect not recognized DataGrip DBE-25433

Age: opened 8 months ago (February 19, 2026). Vendor reproduced it the same day; marked "Fixed in Branch" on September 2, 2026.

Votes / comments: 0 / 1.

The vibe: PostgreSQL 17 added AT LOCAL next to AT TIME ZONE, and the editor only knew the older one. A tidy report, answered the same day. This is the speedy one of the batch.

Credit: Andrew Lazarus (drlaz) reported it.

SQLly: we checked, and SQLly doesn't have this problem. SELECT current_time AT LOCAL validates clean. (changelog)

Support EXPLAIN options added in PostgreSQL 16+: MEMORY, SERIALIZE, GENERIC_PLAN, EXPLAIN MERGE INTO DataGrip DBE-26790

Age: opened 2 months ago (August 5, 2026). Marked "Fixed in Branch" on September 2, 2026.

Votes / comments: 0 / 0.

The vibe: four new EXPLAIN spellings, one false error each, and a knock-on complaint that $1 inside a generic plan "could not be resolved as a column". A thorough report that lists exactly which PostgreSQL version added what.

Credit: Mikhail Zakurdaev (mikhail.zakurdaev) reported it.

SQLly: we checked, and SQLly doesn't have this problem. All four statements validate clean, $1 included, and SQLly doesn't prompt for a value for $1. The Explain button's options menu also offers GENERIC_PLAN and MEMORY, greyed out on servers too old for them. (changelog)

Support JSON_EXISTS, JSON_QUERY and JSON_VALUE functions DataGrip DBE-26807

Age: opened 2 months ago (August 6, 2026). Marked "Fixed in Branch" on September 2, 2026.

Votes / comments: 1 / 0.

The vibe: the SQL/JSON query functions from PostgreSQL 17, reported as "Unknown database function" with their PASSING, OMIT QUOTES and RETURNING clauses underlined. Three lines of SQL, one screenshot, no drama.

Credit: Anastasia Zhukova (anastasia.zhukova) reported it.

SQLly: we checked, and SQLly doesn't have this problem. All three validate clean and highlight as built-in functions on PostgreSQL. (changelog)

EXECUTE IMMEDIATE: Syntax highlighting for IMMEDIATE. HeidiSQL #2619

Age: opened 3 weeks ago (September 30, 2026). Last vendor reply 10 days ago.

Reactions / comments: 0 / 1.

The vibe: the gentlest request of the day: one keyword isn't colored, and here is a link to a fork with the one-line fix. The maintainer replied that the patch fits only the classic Delphi build, which is now feature-frozen while version 13 moves to a Lazarus codebase where keywords work differently. A good patch that arrived during a move.

Credit: @Friedrich2 asked for it and wrote the patch; maintainer @ansgarbecker explained the codebase change.

SQLly: we had this one too, now fixed. SQLly's MySQL and MariaDB vocabulary had EXECUTE but not IMMEDIATE. It is now a keyword, and EXECUTE IMMEDIATE shows up in completion with a description. (commit 537b4c62)

Built-in function not found when "Validate functions" is enabled DBeaver #42372

Age: opened 9 days ago (October 12, 2026). No vendor reply yet.

Reactions / comments: 0 / 2.

The vibe: switch on function validation, and if(), greatest() and instr() come back "not found" while your own test.f() passes. A neat little reproduction script. A contributor dug in two days later, diagnosed a missing list plus a case-sensitive comparison, and offered to fix it; the reporter then showed that INSTR fails even though it is on the list.

Credit: @WEGFan reported it and added the INSTR case; @Suvrat1629 diagnosed it.

SQLly: we checked, and SQLly doesn't have this problem. SQLly never reports a function name as unknown, so there is no list to fall out of date, and IF, GREATEST and INSTR highlight as built-in functions in any letter case. (commit 537b4c62)

Unbounded Rows Preceding No longer works DBeaver #42337

Age: opened 2 weeks ago (October 7, 2026). A reply the next day asked which database and for a video; the issue now carries a "wait for response" label.

Reactions / comments: 0 / 1.

The vibe: the shortest report of the day and the most unnerving: any query with this window frame "does not attempt to run. No error, no timeout, nothing." Silence from the app is worse than an error message. The template's other fields are empty, so the follow-up questions are fair.

Credit: @poverberg6 reported it; @davestokes asked for details.

SQLly: we checked, and SQLly doesn't have this problem. A query with ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW stays one statement, validates clean in every dialect, and passes SQLly's read-only check on every engine, so nothing on SQLly's side stops it from running. (changelog)

CREATE VIEW with aggregation annotated as invalid SQL Azure Data Studio #26268

Age: opened 1 year, 6 months ago (March 31, 2025). No vendor reply, ever.

Reactions / comments: 0 / 1.

The vibe: a view with STRING_AGG … WITHIN GROUP is marked invalid, even though it creates fine and queries fine. One other user tried it four days later, could not reproduce it, and asked how exactly it was marked. Then nothing for eighteen months, which settles nothing.

Credit: @jbauerrfid reported it; @LarnuUK tried to reproduce it.

SQLly: we checked, and SQLly doesn't have this problem. The reporter's exact view validates clean on SQL Server. (changelog)

The score

Twelve issues, four products. SQLly had two of the bugs (one of them found on the way to another issue) and fixed both today; the other ten are now guarded by tests built from the reporters' own SQL. Thanks to everyone above who took the time to write the SQL down. It made checking easy.

Download SQLly