Liquibase resolves/interpolates environment variables in SQL files

I have an SQL file like this with a variable:

INSERT INTO ATABLE VALUES ('${MY_VAR}');

I set on my shell

export MY_VAR=ABC

Now I run liquibase.sh to apply my SQL to the DB. I can see that in my database it contains the value ‘ABC’.

I can see from the documentation that this mechanism is supported 1, but documentation states it should only do this for variables starting with ‘LIQUIBASE_’. Why is it still doing it for my variable?

I am asking because we are seeing this replacmenent of environment variable in an inconsistent manor. It happens for some variables but others not and i would like to understand what is expected from liquibase product side. Should it replace random variables that do not start with the LIQUIBASE_ prefix or not?

I also see this thread that suggests that it will replace any environment variables but to me it does not align with what is in the documentation.

Using liquibase: org.liquibase:liquibase-core=4.20.0

1 Like

I am having the same issue over here. I always need to run the liquibase scripts from a subshell to de-couple it and avoid the liquibase.sh script to replace my ${MyVariable} in the sql scripts. We like to evaluate those variables during the runtime of our app and not during the execution of the database scripts.

Would be interested in clarity as according to the documentation only LIQUIBASE_ prefixed varibales should be resolved.

I agree that liquibase shouldn’t interpolate just any varables. However, there is another workaround than a subshell: From the docs:
Note: If you do not want to replace an otherwise matching ${property-name} expression, add : to the beginning of the expression. An expression of ${: property-name} will always be converted to ${property-name} regardless of whether property-name is defined.

I see now it is documented at the examples:

So, it would be hard to change (perhaps behind a flag).