User Parameters not working as expected

@Peter Heaton  Hi,

Could you specify your Regex and Database > User Parameters settings window screenshot?
Thank you.

@vasil chernov

Thanks for responding. Here is the screenshot you requested and I've circled the two parameter patterns I have added. This was my attempt to get DataGrip to recognize the user parameters that are in all of my existing scripts. It works except in when the parameter is inside a string literal as described in my original post. Any insight you can provide would be very helpful.

Hi,

There are some tickets concerning your problem:

• https://youtrack.jetbrains.com/issue/DBE-5188
• https://youtrack.jetbrains.com/issue/DBE-4614
• https://youtrack.jetbrains.com/issue/DBE-4957

Thank you.

So it sounds like it's a known bug. Hopefully it will get fixed soon. My team has hundreds of scripts with user params inside strings, so adopting this software more broadly within our team will likely be dependent on this issue being resolved.

We would like to see this resolved as well - anything inside of 'here'  is ignored and treated as immune to user parameterization.

Anyone have any suggestions or workarounds?  In our case it's taking javascript literal templating in the form of column='${name}'  if we write column=${name} then it picks up the user parameterization and replaces it but we have to write in the '' directly into there -- and we're not able to copy the SQL directly out of our code base.

@Vasily Chernov, JetBrains…. is this issue resolved?  It, for something that is elementary - (more than) half a decade later for me, still not working.  

I have tried to use: 

1. different supported patterns

2. different custom patterns

3. renaming the parameter

4. in  a query with 4 parameters, same pattern, it resolves 3 of the parameters, but not the 4th.    Really simple stuff … not working.  If I am incorrect, please help me and I will humbly (and gladly) apologise.

This is an absolute nuisance, as it stops one from creating and reusing SQL not only inline, but the capability to reuse and test SQL conveniently - as file in  DataGrip, as resource loaded from code, and inline in code.  Again, and I hope you gather my enthusiasm…

Non-essential SQL stripped

DECLARE
    phases CURSOR FOR
        SELECT *
        FROM "device-3"."sdlc_cmu_stream"
        WHERE timestamp BETWEEN ${after} AND ${before}
        ORDER BY timestamp;
    rec       RECORD;
BEGIN
…
        newRed := rec.red & (1 << ${phase}) != 0;
        newYellow := rec.yellow & (1 << ${phase}) != 0;
        newGreen := rec.green & (1 << ${phase}) != 0;

            INSERT INTO phase_change
            (timestamp, cmu_id, radar_id, is_red, is_yellow, is_green)
            VALUES (rec.timestamp, rec.id, ${radar}, isRed, isYellow, isgreen);
        END IF;
    END LOOP;
    CLOSE phases;
END;

${after} - works

${before} - works

${radar} -works

${phase} - FAILS - not in the parameters popup…  to add salt to the wound it even highlights it consistently with other parameters.  

Postgres, no custom parameters… the default parameters provide for ${} pattern.

Use the above code…  just remove the …  You wil find that in the latest DataGrip that it is not picking up the ${phase}….   neither in IntelliJ (I guess it is the same “infrastructure” so that is expected).

I yesterday updated to the new version of IntelliJ - retested it now - now it works…  Exactly the same query; it is now picking up the phase parameter.  Should have given you screenshots…  for now you think I am crazy.