Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq

On Sunday, February 17, 2013 8:44 PM Phil Sorber wrote:
> On Sun, Feb 17, 2013 at 1:35 AM, Amit kapila <amit(dot)kapila(at)huawei(dot)com>
> wrote:
> > On Tuesday, February 12, 2013 2:49 AM Heikki Linnakangas wrote:
> > On 04.02.2013 17:32, Alvaro Herrera wrote:
> >> Phil Sorber wrote:
> >>> On Mon, Feb 4, 2013 at 10:16 AM, Alvaro Herrera
> >>> <alvherre(at)2ndquadrant(dot)com> wrote:
> >>>> Phil Sorber wrote:
> >>>>> On Mon, Feb 4, 2013 at 9:13 AM, Alvaro
> Herrera<alvherre(at)2ndquadrant(dot)com> wrote:
> >>>>
> >
> >> I think this patch would simplift the patch to pass a connection
> string
> >> to pg_basebackup and pg_receivexlog:
> >> http://www.postgresql.org/message-
> id/005501cdfa45$6b0eec80$412cc580$(at)kommi@huawei.com.
> >> I note that pg_dumpall also has a similar issue as pg_basebackup and
> >> pg_receivexlog; there's no way to pass a connection string to it
> either.
> >
> > I have looked into both patches and my analysis is as below:
> >
> > In pg_basebackup patch, we have connection string and list of
> keywords (individual options specified by user),
> > in the current available patch it has combined connection string and
> list of keywords as connection string
> > and called PQconnectdb() which takes connection string as input.
> >
> > Now the patch of Phil Sober provides 2 new API's
> PQconninfoParseParams(), and PQconninfodefaultsMerge(),
> > using these API's I can think of below way for patch "pass a
> connection string to pg_basebackup, ..."
> >
> > 1. Call existing function PQconinfoParse() with connection string
> input by user and get PQconninfoOption.
> >
> > 2. Now use the existing keywords (individual options specified by
> user) and extract the keywords from
> > PQconninfoOption structure and call new API
> PQconninfoParseParams() which will return PQconninfoOption.
> > The PQconninfoOption structure returned in this step will contain
> all keywords
> >
> > 3. Call PQconninfodefaultsMerge() to merge any default values if
> exist. Not sure if this step is required?
> >
> > 4. Extract individual keywords from PQconninfoOption structure and
> call PQconnectdbParams.
> >
> >
> > Is this inline with what you have in mind or you have thought of some
> other simpler way of using new API's?
> >
> > With Regards,
> > Amit Kapila.
>
> I think what would be nice is an additional connect function that took
> PQconninfoOption as a parameter. Or at least something that can
> convert from PQconninfoOption to a connection string or keyword/value
> arrays.

Yes, it would be better if we would like to use new API's, I think it can
save step-4 and some part in step-2.
I am not sure for this purpose would it be okay to introduce new Connect
API?

I also feel it will increase the scope of patch.

Heikki, would you be more specific that what in the patch you want to see
simplified.
Is the combining of keywords and connection string makes you feel the area
where patch can be improved.

With Regards,
Amit Kapila.