Password with Special Character

[LalunaFish]

I'm trying to do an initial schema build. We have an environmental wide special character requirement, and I'm receiving the error ["can't read xyz": no such variable]. I've tried putting a backslash on the front of the password to no avail. Any help is appreciated. Thank you.

[sm-shaw]

By default the special characters are intepreted so you need to wrap them with curly braces. So taking an example (tested with Oracle) giving a password of {tpcc$xyz} in the GUI was sufficient for the schema build.
In loading the driver script this then gives a connect string as follows:
set connect tpcc/{tpcc$xyz}@VULPDB1 ;#
This needs to be expanded as below to include the entire connect string in curly braces in the script editor.
set connect {tpcc/tpcc$xyz@VULPDB1} ;#
Having done this allows the special character in the password for both build and test.

[fbrendel]

Simply putting the password (containing a $ sign) in curly braces doesn't help with postgres.
I still get a password authentication error for the schema build.
Any other hints to get this working?

[LalunaFish]

Frank, I could never get it to work. I ended up creating an account with its own password policy to not require special characters to begin benchmarking. Regards, Jeff McGettigan

…

On Tue, Jul 28, 2020 at 11:41 AM Frank Brendel ***@***.***> wrote: Simply putting the password (containing a $ sign) in curly braces doesn't help with postgres. I still get a password authentication error for the schema build. Any other hints to get this working? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/TPC-Council/HammerDB/issues/90#issuecomment-665115258>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI2BETGTB4AOS2FKWT5Z4OLR53WQXANCNFSM4KGUOI3A> .

[fbrendel]

Hi Jeff,

and how did you built the schema then?
AFAIK the user building the schema needs superuser rights.

Cheers!

[sm-shaw]

Hi,

There are a couple of ways to prevent the $ being evaluated as a variable. Firstly as you say with the curly braces and secondly with the subst command with the novariables argument. it depends on what password and where it is being evaluated on whether this passes all the way through the stack.

% set password pass$word
can't read "word": no such variable
% set password {passw$ord}
passw$ord
% puts $password
passw$ord
% puts [ subst -novariables $password ]
passw$ord
% puts [ subst $password ]
can't read "ord": no such variable
% 

In v4.0 a new feature for PostgreSQL has been added where the database can be created first and then this will be used instead of needing to create one that needs the superuser permissions.

Steve

[fbrendel]

Hi Steve,

I'm not a Tcl expert. I simply wanted to use a more or less secure password.

The good news is that I got it to work.
I simply changed the connection string in the lines 1313 and 1320 from a list to an URI.
pg_connect -conninfo "postgresql://$user:$password@$host:$port/$dbname"
Then I used the URL encoded $ sign (%24) in the password (e.g. change pass$word to pass%24word).

Regards,
Frank

[fbrendel]

I've changed the pg_connect stuff in the files pgotc.tcl, pgoltp.tcl and pgolap.tcl from the src/postgresql directory.
Works like a charm 😃

[sm-shaw]

That's great and the real benefit of being open source so you can change exactly what you need to