At the moment the SQL language support resolves against the combined set of SQL DDL files found in the project (if I understand correctly).
A project may not always contain an up-to-date or complete set of DDL scripts.
It would be nice if I could use a real datasource instead.
Navigation and resolving could use a read-only/generated DDL script, similar to how resolving to binary Java code uses a decompiled stub.
Of course, such 'synthetic' DDL would probably only contain only generic SQL DDL CREATE TABLE etc statements, missing out vendor-specific extensions like custom index options, etc. But I think that would be fine.
Having such a feature would open the path to other interesting functionality: previewing table and column contents (for example: first 15 rows), executing queries, etc.
But if you also have "create table table1 (...);" statement, then ctrl+b jumps to that statement.
There are at least two open questions here:
1) how to select correct data source (several data sources may contain same named table),
2) should the reference be resolved into existent "create table" statement after that.
Regarding point 1. It could be possible to tie particular .sql file to particular data source. It would be solution for point 1, and also user will not have to specify .sql dialect in project settings / file/directory options.
The GUI for this operation could be similar to existent GUI to define JSP and ant script contexts. (You can open some ant script, imported into another one, in the editor. Then click on Hector's head in status bar and specify, what super-script imports this one. This affects resolving of identifiers in imported script. Settings are stored in project file.) The same way, user could select a data source for .sql file.
@see IDEADEV-27145