On Sat, Jan 22, 2011 at 9:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
