Re: [HACKERS] PQconnectdbParams vs PQconninfoParse
On 23 June 2016 at 21:59, Tom Lane wrote: > Craig Ringer 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
Re: [HACKERS] PQconnectdbParams vs PQconninfoParse
Craig Ringer 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
[HACKERS] PQconnectdbParams vs PQconninfoParse
Hi all 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? 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? Like: PQconnectStartInfo(PQconninfoOption options) PQconnectdbInfo(PQconninfoOption options) ? PQconnectStartParams(...) and PQconnectdbParams(...) would become thin wrappers around it. It's a pity that the name PQconnectdbParams is already taken, really. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
