Let’s look at what’s inside the first EAP build.

New UI

The new UI is now enabled by default for this EAP cycle. Exclusively in DataGrip, all the toolbar icons have been moved to the header:

To configure which buttons you want to see in the header, click the … icon:

If you don’t like the way that looks and would rather use the toolbar stripes, turn this setting off from the Find Action (Ctrl/Cmd+Shift+A):

Connectivity

• SSL

There are now more options for connecting with SSL certificates.
Now you can explicitly set which trust store DataGrip will use for SSL CA files:

The IDE trust store can be configured here:

Another improvement has to do with JKS KeyStore files. Now you can pass *.jks files instead of a CA Certificate and a Client Key.

• HTTP proxy

HTTP proxy settings are now also used in the remote development process. This means that if the driver also uses the HTTP proxy, you can set it in the settings and the connection will work.

Coding assistance

We’ve added many new settings for qualifying objects. Now you can separately detect not only the objects to qualify identifiers with, but also where the qualification should happen.

The whole block of settings has been moved to the Code Completion section.

WSL support for dump tools

The integration with MySQL and PostgreSQL dump tools now supports using WSL paths:

The path to the file is specified in the Windows format, but when creating a process, DataGrip will automatically replace it with the Linux format.

Modify Object

In the Modify Table dialog, putting the caret on the family node will open the table view, which helps you inspect similar objects.

Data editor

• Time zones

With the new setting, you can now set the time zone in which the datetime value should be displayed:

• Show all columns

A new Show all columns action is now available from the header context menu. It helps you find any columns that you may have hidden before.

• Preview in settings

Now, when you change any settings in Settings/Preferences | Appearance & Behavior | Data Editor and Viewer, a preview is available.

[Redshift] Support for External Database/Datashare

The shared databases and their contents are now introspected. The datashares that these databases are created on are also introspected.

Also:

• Shared databases and data shares can be modified with Ctrl/Cmd + F6.
• Last but not least, all the related statements are supported in the SQL editor.

Fixes and improvements

• DBE-13734: [MySQL] SELECT INTO is supported inside stored procedures.
• DBE-17005: [MySQL] The JSON_TABLE function is supported.
• DBE-15065: [Oracle] Code completion works for synonyms.
• DBE-9175: [Oracle] The XMLELEMENT function is supported.
• DBE-16823: [ClickHouse] IPv6 values are displayed correctly.
• DBE-7474: [H2] There are no more false positives for the unresolved variable inspection.

Try out the first EAP build and let us know what you think. We look forward to hearing your feedback, especially about our new UI.

• DBE-16982 A memory leak that occurred when exporting data to a file has been fixed.
• DBE-17820 Add/Clone/Delete Column menu items no longer disappear when editing a CSV file in table mode.
• Several bugs in the SQL formatter have been fixed.
• DBE-18003 The source text is now generated correctly in the Create view dialog.
• DBE-17929 Node disabling for SQL resolution scopes now works correctly.
• DBE-17898 [PostgreSQL] PostgreSQL 16 detection has been fixed.
• DBE-17796 [SQLite] Partial index generation has been fixed.
• DBE-17783 [Azure] The default browser now opens as expected when connecting.
• DBE-15989 [Redshift] External schemas are now clearly distinguished on the Schemas tab in data source properties.
• DBE-17813 [MySQL] Explain plan submenus are displayed correctly for MySQL Aurora.
• DBE-17846 [MySQL] Duplicated collations have been removed from DDL types.
• DBE-16995 [Snowflake] The LIKE ALL operator is now supported.
• DBE-17916 [Snowflake] New aggregate functions are now supported.
• DBE-17261 [Snowflake] The functions MIN_BY and MAX_BY are now supported.
• DBE-17833 [Snowflake] We’ve added support for string literals as a body for Snowflake Scripting procedures.
• DBE-17912 [Snowflake] Highlighting for Python user-defined functions has been fixed.

Nextcloud

Frankly, I don’t like Dropbox. For myself and a couple of friends, I self-host Nextcloud, an alternative to Dropbox. Nextcloud is much more powerful, featuring a vast assortment of supported plugins, which the Nextcloud people refer to as “applications”. It has an application for to-do lists, an application for creating polls, and an application for having Google-like Memories and whatnot. It’s written in PHP and (more importantly) uses MySQL as a database.

How many tables could there be in such an application? If I didn’t know any better, I’d say something like “two: users and files”. However, there are also some maintenance and versioning routines, so you probably also have to account for tasks, versions, preferences, and so on. Here’s what it looks like in reality:

No joke – there are a whopping 199 tables! They mostly don’t have references between them. I think this is a legacy of MyISAM, which didn’t support references at all. By the way, if you know the actual references, you can create them right inside DataGrip with the Create virtual reference action.

What are all those tables? For example, here is everything related to files:

After careful consideration, we understand why it works this way. File locks are needed should one file be changed from different locations.

Trash, for example, is also just pure metadata when you think about it – it has a different physical location from anything else in the store, and it should be possible to clean the trash entirely, partially, or maybe even recover it!

Here’s what the trash table looks like:

Hopefully, this image alone gives you an idea of how enormous the whole thing is. And since I’m hosting it myself, I’m solely responsible for its performance. This is usually a good thing because I can learn a lot and help a lot of people (after all, knowledge is what makes me a good Developer Advocate). But on the other hand, it means there’s a lot of pressure on me! What if the performance becomes so poor that the server starts failing the people who rely on it?

If you’re still unsure about the quality of Nextcloud itself, I just want to say that it’s an excellent piece of software! Many people and organizations use it successfully, myself included!

But three weeks ago, I had some bad luck when my instance of Nextcloud became terribly slow. I didn’t know what happened. I didn’t change anything. “Too much data” would be one possible explanation, but I only have 150 GB of data, so what could have gone wrong?

Debugging

The first step I took was connecting to the database of my Nextcloud. Of course, it’s not exposed to the internet, so I needed to use an SSH tunnel to do this, as shown here:

It’s so simple, and the configuration even supports parsing of the `~/.ssh/config` file! Then, I entered my login and password:

I realized the IDE is actually smarter than me: I constantly forget what arguments I should use with SSH to establish an SSH tunnel. I just had to click the “Test connection” link, and:

But you know what’s even more impressive? This small notification:

To be honest, I sometimes forget that I use MariaDB, not MySQL. And I didn’t even know that it has its own JDBC driver. You bet I want it!

As a second step, I tried to understand what was causing my instance of Nextcloud to run so slowly. It’s simple in MariaDB – even more straightforward than in Postgres (I’m much more familiar with it than with DBs that resemble MySQL):

SHOW PROCESSLIST;

Since I would rather not have to memorize vendor-specific clauses, I created a virtual view in DataGrip:

What did I see in the output? Something like:

UPDATE
  `oc_authtoken`
SET
  `last_activity` = 1680386487
WHERE
  (`id` = 16684)
  AND (`last_activity` < 1680386472);

I didn’t have any idea what it meant, and to be honest, I wasn’t sure how to optimize it. I wanted to start by checking indexes.

In my fevered imagination, having an index on the ID should make this query instantaneous. And yet, I was looking at this query for almost a minute!

When I realized that this was happening with other queries, too, I started googling. But beyond the obvious “check indexes,” there was almost no information. I then started googling things like “MySQL query optimizer”. Of course, the first few results were about EXPLAIN and ANALYZE, but frankly, they’re alien to me in MySQL. Even the nice visual representation I could see in EXPLAIN didn’t help me much:

But then, a miracle was found. And its name was EverSQL.

EverSQL

EverSQL is a SaaS SQL optimizer for several databases, including MySQL and its flavors, as well as Postgres and its flavors. When I signed up, I got one credit for free. Credits are a virtual currency for “buying” single optimizations. What is required for optimization? Two things:

1. The query you want to improve (in my case, it was that UPDATE statement).
2. A database description in a special format: EverSQL generates a crazy SQL query that I won’t even paste here. The query produces a huge JSON with the full description of the database: tables, columns, constraints, and indexes. No actual data goes to EverSQL, so you can rest assured that your data is not being shared.

The story wouldn’t be any fun without a few failures, right? Well, I managed to screw up the second step 🤦🏽. I issued that huge SQL query on the wrong console and got a schema for a completely different database. Be careful, do not repeat my mistakes!

But I was brave and lucky, and when the team from EverSQL (the co-founders, no less) dropped me a line and asked if I had been able to solve my optimization question, I didn’t blindly delete the message (as sometimes I do with marketing emails). Instead, I told them my sad story, and they were kind enough to give me several credits in order to experiment with EverSQL. On the second try, I was careful and issued the correct query in the correct DB schema. They even gave me some advice on how to improve my query. I just needed to add a new index. I no longer have the original recommendation, but it was something like this:

CREATE OR REPLACE INDEX oc_authtoken_idx_id_last_activity
    ON oc_authtoken (id, last_activity);

While it may seem obvious to those who know what’s going on, it’s still a mystery to me why this recommendation improves anything. However, the following chart tells you everything you need to know:

This is the average execution time. We can see that it hasn’t spiked all that much recently, but at one point it was around nine seconds. No amount of indexes could save me if the disk was very busy. It’s also worth noting that, if a lot of slow queries run simultaneously, they can negatively affect each other. So I needed a more systematic approach to improve my database performance.

For the usual code, we should run static analysis tools as frequently as possible to control certain code health metrics. The same goes for databases: We should monitor performance. I usually have some performance monitoring tools installed on my self-hosted applications, but not for MySQL. Well, I could check whether there was sufficient space on my spinning drive and enough memory. But that was definitely not enough.

This is where the second exciting feature of EverSQL came into play: sensors!

EverSQL sensors

A sensor is a small, non-intrusive daemon that monitors slow log, CPU, and additional external signals. Basically, the installation consisted of only two steps:

1. Changing the MySQL settings to publish a slow log to a particular destination, as described here.
2. Installing the sensor (that is just a Python file) to a specific location.

After that, the sensor sent all the slow queries to EverSQL’s servers so that they could analyze patterns and find bottlenecks. After a couple of weeks of reporting and some optimizations, the resulting dashboard looked like this:

Do you see the improvement basically everywhere? Hopefully, it’s the result of adding approximately 8 indexes recommended by EverSQL. Some optimizations appeared later than others, so don’t waste all your credits on the first day!

Then, after about a week of work, something even more interesting appeared on the dashboard!

Every “Show me” button turned on a filter on the dashboard. Yes, it recommended not only adding indexes but also deleting some, like these:

I also had to click this checkbox in the settings:

That’s because I don’t actually manage the code of Nextcloud. Otherwise, I would have probably gotten even more recommendations on how to tune my queries to make the database perform even better.

But what if you’re writing the code and want it optimized? We’ve got a solution for you. There is an EverSQL plugin for our IDEs!

EverSQL plugin for JetBrains IDEs

The actual name of the plugin is “SQL Optimizer,​ Indexing Advisor,​ MySQL,​ PostgreSQL,​ by EverSQL”. It is compatible with the whole spectrum of our IDEs, which is a smart move, since people work with supported databases from almost every language.

Here is what it looks like in Marketplace:

Its working principle is straightforward: Just type your query, select it, and in the context menu, choose “Optimize”.

After that, you will be taken to the same interface of EverSQL in your browser with a dialog like this:

There, you’ll be able to see all the recommendations for optimization immediately.

In conclusion

One’s choice of tools is essential. For me, the choice is always apparent – if I can control something, I will. But sometimes having this control exposes gaps in my knowledge, and I have to use other tools to close those gaps.

DataGrip helps me be as effective as possible when working with databases.

Nextcloud allows me to take control over my data (and sync my photos to my server, not Google’s),

And EverSQL helps me where I’m just not good enough – in the optimization of my queries in my production. The tool is definitely worth trying.

• DBE-17815 The delay in showing database object tooltips is back.
• DBE-13830 External schemas are now shown correctly in the Database Explorer.
• DBE-17380 We’ve fixed an issue with the unresponsive Сancel button in the Modify dialog.
• DBE-16138 Autocompletion in the data editor filter field functions properly. 
• DBE-17609 The Save LOB action works correctly for in-editor results.
• DBE-17537 SingleStoreDB is now recognized correctly.
• DBE-17822 [PostgreSQL] We’ve fixed the permission issue that was causing synchronization to stop.
• DBE-17650 [MySQL] Unsupported SSL protocol errors are detected properly, and quick-fix suggestions are now shown.
• DBE-17447 [MySQL] The ALTER COLUMN syntax that changes the column default value has been fixed.
• DBE-17733 [MySQL] Creating users from the console now triggers automatic introspection. Users are shown in the database tree.
• DBE-17849 [Microsoft SQL Server] We’ve fixed an introspection issue that previously occurred when connecting to Microsoft SQL Server 2005/2008.
• DBE-16918 [Microsoft SQL Server] The Add Row action is now enabled for tables with generated columns.
• DBE-17720 [SQLite] Automatic data source creation when opening SQLite files works correctly.
• DBE-17388 [Snowflake] Schemas with over 10,000 columns now load successfully.

For DataGrip 2023.1, we focused entirely on quality. We’ve fixed many bugs that had accumulated in our public issue tracker (not the most fun part of the job, but important nonetheless).

While there won’t be any new features for you to explore this time, we hope you’ll notice improvements in your daily work with DataGrip.

Here are a few of the highlights, and for a full list of bug-fixes with more details, please visit our What’s New page.

Working with code

• DBE-4469: We fixed the problem causing the SQL Formatter not to apply the correct style for subqueries in EXISTS clauses.
• We fixed many bugs concerning syntax support across different databases.

Database explorer

• DBE-17263: Data source content statistics are again displayed in the Quick Documentation popup.

• DBE-17166: Renamed folders in the database explorer no longer disappear.

Data editor and viewer

• DBE-3572: We’ve added an Alternate row colors setting for results tables. When this setting is enabled, rows will be displayed in alternating colors.

• DBE-16250: There are no longer empty spaces in the in-editor results, as the table now automatically adjusts to the height of the results.

• Support request: Image preview works correctly in the value editor.

Object editor

• DBE-16393: We’ve added a source editor to the Modify view.

• DBE-17329 [PostgreSQL]: Virtual view creation is now also available in read-only mode.

Query console

• DBE-14074: Named parameters are detected correctly.
• DBE-10555: Whenever you copy and paste something, the IDE now correctly analyzes the selection (instead of the cursor position).
• DBE-17362: The schema switcher works properly in the new UI.

SQL resolve

• DBE-16831: A setting to specify the default resolve mode used in the console has been added to Preferences | Database | Query execution | Other.

• DBE-5497 [Oracle]: We fixed a few problems with Oracle collection methods.

Diagrams

• DBE-17137: We fixed a bug where the IDE would only show the Explain Plan diagram for the first of several queries.
• DBE-16238: Error notifications no longer appear when saving a diagram.

Introspection

• [Oracle] We’ve implemented several improvements to speed up the introspection process.
• There are many fixes related to introspection issues for Microsoft SQL Server, MySQL, PostgreSQL, and Db2.

Schema diff 

• DBE-17229: The Schema diff viewer now works properly; previously, ‘Nothing to show’ was displayed if database or server objects were included.
• [Microsoft SQL Server, PostgreSQL, Db2] You can now use the Specify next value for sequences option to control the behavior of sequences that have a start value.

That’s it for the overview! If you are interested in making the move to version 2023.1 or getting in touch with us, here are a few links that you might find useful:

• Download DataGrip 2023.1
• Visit our What’s New page for a full list of bug-fixes
• Tweet @ us!
• Please report any bugs to our issue tracker.

The DataGrip team

This is the release candidate for 2023.1 Quality Release. Check out these publications for a reminder of what we’ve managed to fix:

2023.1 EAP 1
2023.1 EAP 2
2023.1 EAP 3

Try it out and share your feedback with us! 

Introspection

[Oracle]: We’ve implemented several improvements to speed up the introspection on Level 1. Here are a few tips to speed up your work, especially if you’re working with a large number of schemas and many database objects:

• Switch the introspection level to Level 1, where DataGrip introspects only the names and types of objects.

• On introspection Level 1, you can click Refresh selected object to edit a specific object or view its sources.

• Check if you have the SELECT_CATALOG_ROLE and the SELECT ANY DICTIONARY permissions, which grant you access to the Oracle internal catalog. This makes introspection much faster.

Code highlighting

• DBE-11727, DBE-11500 [BigQuery]: Alias resolution in UNNEST queries now works correctly.
• DBE-17291, DBE-17449 [ClickHouse]: EPHEMERAL columns, INTERSECT, and EXCEPT clauses are now supported.

Schema Diff

[Microsoft SQL Server, PostgreSQL, Db2]: You can now use the Specify next value for sequences option to control the behavior of sequences that have a start value.

If the Specify next value for sequences option is not enabled, DataGrip generates the DDL of the sequence, adding the start value to the START WITH start_value.

When the Specify next value for sequences option is enabled, DataGrip adds the next value that the sequence should have to the DDL, with a few differences for the following databases:

• [Microsoft SQL Server]: Instead of the sequence start value, the next sequence value is specified in the RESTART WITH clause in the CREATE and ALTER statements.

• [PostgreSQL]: Instead of the sequence start value, the next sequence value is specified in the START WITH clause in the CREATE statement. The start value is specified in the START WITH clause, and the next value is in the RESTART WITH clause in the ALTER statement.

• [Db2]: Instead of the sequence start value, the next sequence value is specified in the START WITH clause in the CREATE statement. The next value is specified in the RESTART WITH clause in the ALTER statement (changing the start value is not allowed in Db2).

Query console

• DBE-17479: Failing queries with the Read access is allowed from inside read-action (or EDT) only notification in the Query console has been fixed with regression.
• DBE-12787, DBE-12109 [Oracle]: The CREATE PROCEDURE and CREATE FUNCTION now end with “;” – as expected.
• [MongoDB]: Loss of values in IN (…) if there are more than 10 has been fixed.

Code completion

• DBE-13506 [MongoDB]: The bug with broken SQL completion for nested properties has been fixed.

Data editor/viewer

• We fixed the image preview in the data grid.
• DBE-13329 [MongoDB]: We added the Change Default action to configure the default page size.

Here’s the list of improvements and fixes you can already try in this EAP build:

DBE-16238: Errors no longer appear while saving a diagram.

DBE-17229: The Schema diff viewer now works properly. Previously it opened empty if there were database or server objects included.

DBE-7087: Usage search no longer looks in the installation bundled resources.

DBE-17434: The correct font color is used in the data editor header.

DBE-17292: The Quick Doc window doesn’t freeze when counting rows.

DBE-17362: The schema switcher works properly in the new UI.

DBE-17375: .ids files can now be opened.

Support request: Image preview works correctly in the value editor.

DBE-17330: [MySQL] The DDL of a table is refreshed after changing a comment in the Modify dialog.

DBE-16576: [PostgreSQL] It’s possible to update a value in a view with the ENUM column.

DBE-17490: [PostgreSQL] The SQL generator quotes correctly in the EXCLUDE constraint.

DBE-7466: [PostgreSQL] Fixed the issue with connecting via pg_bouncer.

DBE-12758: [Oracle] Type attributes are now supported.

DBE-11949: [Oracle] Table types declared in the notation named in the package are now supported.

DBE-16452: [Oracle] Shortcut navigation works for packages.

DBE-14722: [Oracle] JSON columns are supported.

DBE-17166: Renamed folders in the database explorer no longer disappear. 

DBE-14303: [BigQuery] The precision for milliseconds in the TIMESTAMP values is no longer lost. 

That’s it! 

The DataGrip team

Our 2023.1 release cycle is all about quality, which means we’re working on the bugs that have accumulated in our public issue tracker. Today we’ll cover what we’ve managed to fix so far. Of course, you can already get the benefits of these fixes by downloading our EAP build!

Working with code

• DBE-4469: We fixed the problem where SQL Formatter didn’t apply the right style for a subquery in the EXISTS clause.

Now it works as expected, and DataGrip can also add a space between the EXISTS keyword and the left parenthesis. For this part, we also added a new setting. Now, if you want to preserve the old Formatter behavior (without the space), you can change the Space after keyword setting to No in Preferences | Editor | Code Style | SQL (go to the Queries tab).

• DBE-14440 [H2]: We fixed the bug with saving style settings. If you have configured a special style for SQL2016 and the Inherit general SQL style checkbox in Preferences is not enabled, then you will need to reconfigure it.

The other fixes in this area are more or less self-explanatory:

• DBE-15973 [BigQuery]: The WINDOW clause is now supported.
• DBE-9219 [Clickhouse]: Сase settings when completing exact-case names are now ignored.
• DBE-14796 [MySQL]: Problems with LAG and LEAD functions have been fixed.
• DBE-16311 [MySQL]: FOR UPDATE in nested queries is now supported.
• DBE-12139 [MySQL]: The ENCRYPTION syntax is now supported.
• DBE-13186 [Microsoft SQL Server]: Inspections no longer erroneously report extra code.
• DBE-11946 [PostgreSQL]: An issue with Place constraints was fixed.
• DBE-6276 [PostgreSQL]: DDL navigation to security policies now works as expected.

Database explorer

• DBE-17263: Data source content statistics is again displayed in the Quick Documentation popup.

• DBE-10812 [PostgreSQL]: The Drop context menu command now works as expected.

Introspection

• DBE-12578 [Oracle]: Cross database triggers are now supported. You can create a trigger X in schema A to table E in schema B, and it will be shown in schema B under the host table E.
• DBE-6986 [MySQL]: The ROW_FORMAT clause/syntax is now supported.
• DBE-10603 [Microsoft SQL Server]: The Quick Definition now works as expected.
• DBE-9087 [PostgreSQL]: When using the clause REFERENCING, the trigger’s DDL is generated correctly.
• DBE-12404 [IBM Db2]: We fixed an issue with interrupting object introspection. If the user permissions did not allow retrieving a list of database users, the rest of the database objects were not loaded either. Now everything but the list of users will be loaded.

Connectivity

• DBE-16417 [Microsoft SQL Server]: Current schema detection now works for any database.
• DBE-11012 [SQLite]: The SQLite native library is now unpacked to the system folder.

Object editor

• DBE-16393: We’ve added a source editor to the Modify view.

• DBE-17329 [PostgreSQL]: Virtual view creation is now also available in read-only mode.

Data editor/viewer

• DBE-3572: We’ve added an Alternate row colors setting for results tables. When the checkbox is enabled, rows will have alternating colors.

• DBE-16250: There are no more empty spaces in in-editor results, as the table now adjusts its height to match the height of the results.

Query console

• DBE-14074: Named parameters are detected correctly.
• DBE-10555: Whenever you copy and paste something, the IDE now correctly analyzes the selection (instead of the cursor position).
• DBE-12109 [Oracle]: Semicolons are no longer omitted in Oracle Aggregate Functions.
• DBE-16871 [BigQuery]: The Unexpected value error no longer pops up when previewing a table.

SQL Resolve

DBE-16831: A setting to specify the default resolve mode used in the console has been added to Preferences | Database | Query execution | Other.

• DBE-5497 [Oracle]: We fixed a few problems with Oracle collection methods:
  – Public synonyms are now correctly placed in the PUBLIC schema.
  – Recursive references to nested routines are resolved correctly.
  – Cursor parameter references qualified by a cursor name are resolved correctly.
  – Incorrect usages of %TYPE are reported as warnings.
• DBE-12772 [Oracle]: We fixed the resolution of standard attributes for collection types (for example, COUNT).

Explain plan

• DBE-17137: We fixed a bug where the IDE would show the Explain Plan diagram only for the first of several queries.

Navigation and search

• DBE-12015 [Oracle]: Go to Declaration (Ctrl/Cmd+B or Ctrl/Cmd+click) now navigates you to the routine implementation.

That’s it for now! Get the EAP 1 build and try working in DataGrip without these nagging issues. And let us know what you think in the comments below!

• Report new bugs to our issue tracker
• Tweet us!
• Email us at datagrip@jetbrains.com
• Contact our support

• DBE-11963: Auto-refresh is now available with adjustable intervals. It can be disabled manually or automatically (for example, if you start editing).

You can set up auto-refresh for sessions in Virtual views to monitor sessions in real time, which finally resolves this really old ticket, DBE-229! 

• DBE-17059: A list of settings was added to the Object Migration dialog.

• DBE-16936: The Custom color chooser for databases now works correctly.
• DBE-17068: Execute to file now works correctly.
• DBE-16902: [Redis] We fixed the problem with connecting when SSL is enabled. Important: Please update the Redis JDBC driver to v1.3.
• [Oracle] We added more details related to obtaining stored object sources to the Diagnostic Refresh log. This will help us investigate problems when some object sources are not retrieved by the introspector properly.

• DBE-16825: The default name for created objects is selected so that it’s easy to replace it.
• DBE-16899: Virtual views are correctly refreshed.
• DBE-16824: Virtual views can be found via the Search dialog.
• DBE-15968: [PostgreSQL] Database names with slashes are supported.
• DBE-16862: [SQL Server] The correct parameter syntax is generated for stored procedures via the Generate menu.
• DBE-16887: [Redshift] We fixed the problem with introspection for the latest database version 1.0.44126.
• DBE-16829: [Firebird] Keep-alive query works.

With love,

Your DataGrip team