this parsing and generating the port as a double will kill the magic. 5432.0 doesn't match 5432, so you get an exception. libpq: failed (fe_sendauth: no password supplied)
Granted this can be solved by making the port a * wildcard in pgpass, but I may have other reasons for specifying the port there.
Looking at the denominator and parsing denominator=1 ratios as integers this way solves that problem - not sure if it screws with anything else though (options given as integers which for whatever reason must actually be presented as a double with .0? Seems unlikely.)
Other choice is adding integer support to configurator - dunno if that's something desired, anyways. The interpolate function in configurator does something similar to this, though.
getConnectionString
currently makes all numbers in a Configurator.Config doubles; integers end up with .0 appended to them in the generated text.Given a config file with
the generated connection string is
"host='database.at.my.host' port=5432.0 dbname='thedbname' user='myusername' "
If you use a .pgpass file, and in it you specify a port, ex:
database.at.my.host:5432:thedbname:myusername:mypassword
this parsing and generating the port as a double will kill the magic. 5432.0 doesn't match 5432, so you get an exception.
libpq: failed (fe_sendauth: no password supplied)
Granted this can be solved by making the port a * wildcard in pgpass, but I may have other reasons for specifying the port there.
Looking at the denominator and parsing denominator=1 ratios as integers this way solves that problem - not sure if it screws with anything else though (options given as integers which for whatever reason must actually be presented as a double with .0? Seems unlikely.)
Other choice is adding integer support to configurator - dunno if that's something desired, anyways. The
interpolate
function in configurator does something similar to this, though.