On 23 June 2016 at 21:59, Tom Lane <t...@sss.pgh.pa.us> wrote:

> 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?

If you were passing it directly you wouldn't, but it can make sense to
parse it, modify the results and then pass that to a connect function. To
do so now you have to allocate a couple of new arrays and do a bunch of
copying. It's not hard, just a bit ugly and shouldn't be necessary.

> 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.

That makes sense.

> 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.

OK, good point.

Given those points the current situation is not ugly enough to be worth
pursuing when it's not exactly hard to copy the results into key and value
arrays. I was looking at this as a low-hanging API usability wart, and it

Thanks for pointing out the issues.

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to