Re: PQconnectdbParams vs PQconninfoParse

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> While writing some code that takes a connstring and adds some parameters, I
> noticed that PQconninfoParse doesn't play well with PQconnectdbParams.

> PQconnectdbParams takes a pair of equal-length arrays, one for keys and one
> for values, each terminated by null elements. But PQconninfoParse returns
> a an array of PQconninfoOption .

> This means the client has to do a bunch of fiddling to turn a parsed
> conninfo into something that can be passed to PQconnectdbParams . This
> seems bizarre. Am I missing something obvious?

Um, I don't see the connection. Under what circumstances would you want
to pass the result of PQconninfoParse directly to PQconnectdbParams?
PQconninfoOption is intended to provide a lot of secondary information
about the available options, so it's more in the nature of an
informational record than something you would feed back into the library.

> libpq internally uses connectOptions1 which calls parse_connection_string,
> the same function used by PQconninfoParse. But there's no connect variant
> exposed to users to use it.
> Anyone object to adding one?

This seems more like exposing library implementation details than adding
useful functionality.

In particular, I object to using PQconninfoOption as an input data
structure to the library, because then you'd have a bunch of definitional
questions about which fields of that struct the client app is expected to
make valid, plus the potential for well-hidden bugs if some part of the
library unintentionally relies on a field it shouldn't when looking at a
PQconninfoOption that came from outside the library rather than inside.

regards, tom lane