Re: [PATCH] Make pg_basebackup configure and start standby [Review] - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Date
Msg-id 506D14CD.5080602@cybertec.at
Whole thread Raw
In response to Re: [PATCH] Make pg_basebackup configure and start standby [Review]  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] Make pg_basebackup configure and start standby [Review]  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
2012-10-04 05:24 keltezéssel, Peter Eisentraut írta:
> On Wed, 2012-10-03 at 18:15 +0200, Boszormenyi Zoltan wrote:
>> The second generation of this work is now attached and contains a new
>> feature as was discussed and suggested by Magnus Hagander, Fujii Masao
>> and Peter Eisentraut. So libpq has grown a new function:
>>
>> +/* return the connection options used by a live connection */
>> +extern PQconninfoOption *PQconninfo(PGconn *conn);
>>
>> This copies all the connection parameters back from the live PGconn
>> itself
>> so everything that's needed to connect is already validated.
> I don't like that this code maintains a second list of all possible
> libpq connection parameters.

Where does it do that? In PQconninfo() itself? Why is it a problem?
Or to put it bluntly: the same problem is in fillPGconn() too, as it also
has the same set of parameters listed. So there is already code
that you don't like. :-)

How about a static mapping between option names and
offsetof(struct pg_conn, member) values? This way both fillPGconn()
and PQconninfo() can avoid maintaining the list of parameter names.

>    The parameters to add to the connection
> string should be driven off the authoritative list in PQconninfoOptions.

So, should I add a second flag to PQconninfoOption to indicate that
certain options should not be used for primary_conninfo?

Thanks and best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de     http://www.postgresql.at/




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: xmalloc => pg_malloc
Next
From: Michael Paquier
Date:
Subject: Re: Support for REINDEX CONCURRENTLY