Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP)
Date: 2011-04-04 18:58:31
Message-ID: 3490.1301943511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-04-04 19:02:39 Re: [HACKERS] Uppercase SGML entity declarations
Previous Message Kevin Grittner 2011-04-04 18:57:46 Re: Disable optimization when in subtransaction