Peter Eisentraut <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])