allow configuring the Config directly, without having to call `ParseConfig`

[gabor]

Is your feature request related to a problem? Please describe. I work on software where the user fills in the postgres configuration into a form. then i have to construct a connection-string from the data i have (not to forget to escape stuff etc.), and then call ParseConfig.

Describe the solution you'd like A clear and concise description of what you want to happen. I'd like to be able to fill out a go structure (pgconn.Config?) with the info i already collected from the user directly, without having to consruct the connection-string.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Ideally this approach would also skip all the "compatible with C' things, like looking for stuff in default-places, read environment variables etc. but that may be a separate feature request.

[jackc]

You can use ParseConfig(""). Then nilify Fallbacks and set Host, Port, Database, User, Password, and TLSConfig directly.

[gabor]

thanks for the info! will this still look at things like env-variables and default-cert-locations etc?

[jackc]

The environment variables and other default values are all used during ParseConfig. You will be overwriting whatever they were.

[evgenymarkov]

You can use ParseConfig(""). Then nilify Fallbacks and set Host, Port, Database, User, Password, and TLSConfig directly.

It would be great to have the ability to create a Config based on a simplified structure with parameters, for example:

pgx.EasyConfig{
  Host: "...",
  Port: 123,
  Database: "...",
  User: "...",
  Password: "...",
  SSLMode: "..."
}

[rlewis-grax]

I agree that a simplified means of creating a Config using only input parameters would be nice here, especially if doable via the ParseConfig mechanism (or similar). There's a lot of "magic" that happens internally within ParseConfig that cannot be directly controlled by the calling application and which necessitates a level of control over the execution environment that cannot always be guaranteed or easily achieved.

[jackc]

I'm not opposed to this in principle, but it would definitely need some careful thought and consideration. And if something is to be done, it may also be worth revisiting the fallback config system at the same time. It adequately represents common cases such as sslmode=prefer, but more complicated configs are a bit harder to represent and reason about. But again, that would need careful thought.