Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP)
От | Robert Haas |
---|---|
Тема | Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP) |
Дата | |
Msg-id | AANLkTim_J-iQtYK8pzyFJ3jAjgkJnoSOX1y-PCqPaNtT@mail.gmail.com обсуждение исходный текст |
Ответ на | GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP)
|
Список | pgsql-hackers |
On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > IMO the real problem is essentially that GUC assign hooks have two > functions, checking and canonicalization of the value-to-be-stored > versus executing secondary actions when an assignment is made; and > there's no way to get at just the first one. Yes, I think that's right. A related point is that the API for assign hooks is not consistent across all data types: string assign hooks can return a replacement value, whereas everyone else can only succeed or fail. > It would probably take less than a day to flesh out this idea and make > it happen, but it does seem like a rather large change for late alpha. > If people don't want to do this now, I suggest that we just live with > the problem for 9.1. It's purely cosmetic, and easy enough to work > around (just don't uncomment the default value). I think it's a pretty ugly wart, so I'm inclined to say go ahead and fix it. I'm not sure what alpha is for if it's not cleaning up the detritus of all the stuff we've committed in the last 9 months. AIUI, what we're trying to avoid is committing new stuff that may require additional cleanup, not cleaning up the stuff we already did commit. Once we get to beta I'll be less enthusiastic about making changes like this, but I think most of the testing that will get done is still in front of us. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: