On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane <t...@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?
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? -- 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
