Peter Eisentraut <peter_e@gmx.net> writes:
> Fernando Nasser writes:
>> We have a server side GUI utility that among other things let us configure GUC
>> variables. We badly need to know what variables exist in the specific backend
>> version, which are the min and max values and if possible a description.
> In that case I think it's best to put it directly into the server
> executable and add an option like --help-long or possibly some variations
> if you need specific program-parsable formats. This would certainly solve
> a few of the implementation concerns I've heard about, and it's also a
> fairly logical place to look for it.
Hm. We had toyed with that idea for a bit but rejected it on the
grounds that it would add bloat to the postgres executable. On the
other hand, two sets of message catalogs would bloat an installation
even more. Maybe that's the best plan after all.
Aizaz, if you look at backend/main/main.c it should be pretty obvious
how to handle this --- it's just like bootstrap mode. main.c kicks off
control to GucInfoMain or whatever we call it, and then that routine
can act pretty much the same as if it were the actual main() of a
standalone pg_guc. This also eliminates the need for VARADDR() and a
lot of the other thrashing about we were doing to allow creation of
a standalone variable table ... in fact, I think quite a large
percentage of the patch disappears ...
regards, tom lane
