Custom variables and flags, again
От | Tom Lane |
---|---|
Тема | Custom variables and flags, again |
Дата | |
Msg-id | 12680.1226870106@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Custom variables and flags, again
Re: Custom variables and flags, again |
Список | pgsql-hackers |
The auto-explain patch needs a way to set the GUC "flags" for a custom GUC variable; a capability that was unaccountably left out of the original DefineCustomXXXVariable APIs. The original version of the patch dealt with this by changing those APIs, which I complained about here: http://archives.postgresql.org/pgsql-hackers/2008-09/msg00168.php The new version gets around this by leaving those functions alone and exporting a new function void DefineCustomVariable(enum config_type type, const void *variable); to which you are supposed to pass an entire struct config_whatever. I can't say that I find this an improvement. Yeah, it avoids breaking existing code, but the idea that add-on modules should hard-code the exact contents of the GUC structs fills me with horror. What happens when we add some field or other to those structs? I'll tell you what happens: those modules break, nastily and probably silently, because no C compiler I know of is very picky about the contents of a struct initializer. So I think this is just trading short-term pain for a larger amount of long-term pain. On the whole, I think we'd be better off to just add more arguments to the DefineCustomXXXVariable functions, as in the original patch (and while we're at it, fix the problem of where the boot_val comes from, as suggested in the above-referenced message). At least that will result in obvious and easily-fixable breakage in add-on modules that use these functions. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: