Re: PQconnectdbParams vs PQconninfoParse

On 23 June 2016 at 21:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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

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