On Sat, Jan 22, 2011 at 9:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> This is certainly shorter than I wrote, which is good, but it strikes
>> me that the fundamental problem here is that the API for an assign
>> hook is fundamentally different for strings than it is for other data
>> types.
>
> I agree that that's annoying, but given that strings are pass-by-ref
> while the other GUC variable types are pass-by-value, it's not really
> very easy to make them alike.
>
> In any case, it's not too relevant to this patch, because an assign hook
> cannot solve this problem. As someone (I think you) pointed out
> upthread, an assign hook would only be useful if we were sure
> wal_buffers would in fact be assigned to by the config file, and that
> that would happen after shared_buffers acquired its final value. Since
> we can't assume either thing, the right way to approach it is to have an
> internal action that assigns a fresh value to wal_buffers after all the
> configuration processing is complete. Greg had the right design but
> didn't know how to change a GUC setting properly. There are a bunch of
> other hacks^Wfeatures that work similarly --- look around for
> SetConfigOption calls.
I'm going with hacks. Any API that requires you to print to a string
so you can turn around and immediately convert it back to an integer
is not too swift.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
