Craig Ringer <cr...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
