Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP)
От | Tom Lane |
---|---|
Тема | Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP) |
Дата | |
Msg-id | 3490.1301943511@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP)
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Given these rules, a check_hook and assign_hook could cooperate to store >> additional data in what guc.c thinks is just a pointer to a string >> value, ie, there can be more data after the terminating \0. �The >> assign_hook could work off just this additional data without ever doing >> a catalog lookup. �No special show_hook is needed. > The only thing this proposal has to recommend it is that the current > coding is even worse. Well, if you don't like that, do you like this one? >> Another variant would be to allow the check_hook to pass back a separate >> "void *" value that could be passed on to the assign_hook, containing >> any necessary derived data. �This is logically a bit cleaner, and would >> work for all types of GUC variables; but it would make things messier in >> guc.c since there would be an additional value to pass around. �I'm not >> convinced it's worth that, but could be talked into it if anyone feels >> strongly about it. If not, what do you suggest? regards, tom lane
В списке pgsql-hackers по дате отправления: