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 isn't. Thanks for pointing out the issues. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
