2012-10-04 06:47 keltezéssel, Boszormenyi Zoltan írta:
> 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
>>> 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.
Did you think about something like the attached code?
Cybertec Schönig & Schönig GmbH
A-2700 Wiener Neustadt, Austria
In response to
pgsql-hackers by date
|Next:||From: Amit Kapila||Date: 2012-10-04 10:56:30|
|Subject: Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation|
|Previous:||From: Amit kapila||Date: 2012-10-04 10:12:30|
|Subject: Re: BUG #7534: walreceiver takes long time to detect n/w