On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?
To be clear, it's certainly an improvement over what we have now.
>>> 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.
I haven't really got the mental energy to think through all of this
right now in detail, but I think that might be better. I think
there's more kludgery here than we're going to fix in one pass, so as
long as we're making improvements, I'm happy. Is there any case for
using a Datum rather than a void * so people can pack a short quantity
in directly without allocating memory, or are we expecting this to
always be (say) a struct pointer?
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Dave Page||Date: 2011-04-04 19:14:36|
|Subject: Re: [HACKERS] Uppercase SGML entity declarations|
|Previous:||From: Tom Lane||Date: 2011-04-04 19:08:20|
|Subject: Re: [HACKERS] Uppercase SGML entity declarations |