Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq - Mailing list pgsql-hackers
From | Amit Kapila |
---|---|
Subject | Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq |
Date | |
Msg-id | 004f01ce0ea0$017eda90$047c8fb0$@kapila@huawei.com Whole thread Raw |
In response to | Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq (Amit Kapila <amit.kapila@huawei.com>) |
Responses |
Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq
|
List | pgsql-hackers |
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > owner@postgresql.org] On Behalf Of Amit Kapila > Sent: Monday, February 18, 2013 6:38 PM > To: 'Heikki Linnakangas' > Cc: 'Phil Sorber'; 'Alvaro Herrera'; 'Magnus Hagander'; 'PostgreSQL- > development' > Subject: Re: [HACKERS] [PATCH] Add PQconninfoParseParams and > PQconninfodefaultsMerge to libpq > > On Monday, February 18, 2013 1:41 PM Heikki Linnakangas wrote: > > On 18.02.2013 06:07, Amit Kapila wrote: > > > On Sunday, February 17, 2013 8:44 PM Phil Sorber wrote: > > >> On Sun, Feb 17, 2013 at 1:35 AM, Amit > kapila<amit.kapila@huawei.com> > > >> wrote: > > >>> 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? > > > > Yep, that's roughly what I had in mind. I don't think it's necessary > to > > merge defaults in step 3, but it needs to add the "replication=true" > > and > > "dbname=replication" options. > > I could see the advantage of calling PQconninfoParseParams() in step-2 > is > that > it will remove the duplicate values by overriding the values for > conflicting > keywords. > This is done in function conninfo_array_parse() which is called from > PQconninfoParseParams(). > Am I right or there is any other advantage of calling > PQconninfoParseParams()? > > If there is no other advantage then this is done in PQconnectdbParams() > also, so can't we avoid calling PQconninfoParseParams()? ---- > 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 think not only pg_dumpall, but we need to add it to pg_dump. As -C is already used option in pg_dump, I need to use something different. I am planning to use -K as new option(available ones were d,g,j,k,l,m,p,q,y). I am planning to keep option same for pg_dumpall, as pg_dumpall internally calls pg_dump with the options supplied by user. In fact, I think we can hack the string passed to pg_dump to change the option from -C to -K, but I am not able see if it will be way better than using -K for both. Suggestions? With Regards, Amit Kapila.
pgsql-hackers by date: