Re: PQconnectdbParams vs PQconninfoParse

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: PQconnectdbParams vs PQconninfoParse
Дата
Msg-id CAMsr+YGzkZKFb2ELHB0txo6uU4fo2vGeqY8spQUnJoSybzp4ew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PQconnectdbParams vs PQconninfoParse  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On 23 June 2016 at 21:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Craig Ringer <craig@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Postgres_fdw join pushdown - wrong results with whole-row reference
Следующее
От: Haroon Muhammad
Дата:
Сообщение: Re: initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)